* Re: Org and Hyperbole
@ 2022-09-27 15:08 0% ` Russell Adams
0 siblings, 0 replies; 200+ results
From: Russell Adams @ 2022-09-27 15:08 UTC (permalink / raw)
To: emacs-orgmode
On Tue, Sep 27, 2022 at 04:06:17PM +0300, Jean Louis wrote:
> * Tim Cross <theophilusx@gmail.com> [2022-06-21 02:43]:
> >
> > Russell Adams <RLAdams@adamsinfoserv.com> writes:
> >
> > > On Mon, Jun 20, 2022 at 02:03:15PM +0000, Juan Manuel Macías wrote:
> > >> I've been intrigued with GNU Hyperbole for a while. I'm reading the
> > >> documentation and trying it out a bit. It seems that its button system
> > >> is very powerful. But Org links are also powerful (and exportable), and
> > >> can be extended outside of Org docs. It seems that hyperbole offers some
> > >> cool stuff that Org also has. And other things that are not in Org. I
> > >> find some parts a bit confusing. I wonder if anyone is using hyperbole
> > >> with Org and can put here some minimal workflow example where both
> > >> complement each other in some way. Just in case I'm missing something
> > >> useful...
> > >
> > > Juan,
> > >
> > > I've often wondered the same thing. I've looked at Hyperbole several
> > > times. They have been great at advertising when a new release
> > > occurs. Yet I find that I can't really find a useful feature in it
> > > that I don't get from Org-mode.
> > >
> > > Is there some keen feature I'm missing? What's the use case for
> > > Hyperbole if you're already an Org-mode user?
> > >
> > > https://www.adamsinfoserv.com/
> >
> > My experiences with it mirror yours. It looked interesting and there
> > were some ideas which sounded interesting, but when I came to use it, I
> > found little, if anything, which didn't have a close equivalence in org
> > mode and many things in org mode which it did not have.
> >
> > In the end, it came down to asking myself do I really want yet another
> > information management framework in my life and the answer was no. I do
> > vaguely recall (it was a while ago) there were some ideas I thought
> > would be good to add to org mode though. Unfortunately, I cannot recall
> > the details now.
>
> I somehow cannot relate to it, Hyperbole and Org mode are quite
> different things. I have Hyperbole all the time here running, no
> matter if I use Org mode or what other lightweight markup language.
Could you point to some usage of Hyperbole that could help address
it's use case?
------------------------------------------------------------------
Russell Adams RLAdams@AdamsInfoServ.com
https://www.adamsinfoserv.com/
^ permalink raw reply [relevance 0%]
* Re: Create in Org a bilingual book with facing pages
@ 2022-09-27 16:34 4% ` Hendursaga
2022-09-28 6:14 5% ` Juan Manuel Macías
2022-09-28 7:14 7% ` Christian Moe
2 siblings, 1 reply; 200+ results
From: Hendursaga @ 2022-09-27 16:34 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The bilingual critical edition (ancient Greek/Spanish) of the letters of Demosthenes and Aeschines has recently been published in Spain, a book whose production and typesetting I have taken charge of, using Org and Org-publish.
What is the name of this book / the publisher's page? I don't really know Spanish, and only a little Greek, but I'm fascinated by bilingual editions, especially with critical apparati. I've been looking for a workflow for creating my own (possibly critical) bilingual works, but so far, months later, I haven't really found anything satisfactory.
> First of all, for this kind of work you have to take into account an inherent limitation of TeX: the compilation process in TeX is a single-threaded process. That is, in TeX you cannot compile different parts of a document, with different configurations (= different preambles), at the same time.
To clarify: you mean that you would have to have two distinct documents so that, say, the page titles, fonts, indices, etc can be specific to that "language half" of a work? I would've thought you could just have everything in one document. That's how I've been (trying to) do it so far, using the reledpar package, an extension of reledmac. Did you / have you tried using that? I've also tried various other packages, like the parallel package.
> On the other hand, since in this book the content of the odd and even pages is variable, the synchronization has been done per page, so that the reader always obtains the same content on the odd and even page when facing the open book. For the Greek document I used the reledmac LaTeX package[...]
I've looked at reledmac, and I agree, it is pretty sophisticated. Can you clarify which synchronization method(s) you use? If you do use reledpar, in section 6.2.2, it lists the different ways you can synchronize. Otherwise, could you try to explain in terms it uses?
> Once both PDFs are obtained and synchronized, they are loaded into the master Org document using the pdfpages LaTeX package. Since it was necessary to introduce in certain pages some commands specific to each page, such as page styles, index entries or labels for references, and to avoid having to load the pages one by one with pdfpages commands, I wrote a function that obtains the number of pages of the synchronized PDF (via mutool) and it does all that work. [...]
To clarify once more: when you introduce page-specific commands, is this in the original PDF documents that you generate, or are those, like, trimmed and then you add on the headers etc later, or what?
> And that’s it. The next challenge for this fall is going to be a trilingual edition of the New Testament (Greek, Latin, Spanish). [...]
Are you aware of Kevin Klement's trilingual edition[1] of Wittgenstein's Tractatus Logico-Philosophicus? (OK, it's technically bilingual, but with two separate English translations along with the original German!) He uses PHP (gross, I know!) to collate everything into a LaTeX document to then generate the various final versions. Besides the PHP, you might pick up a technique or two! (Or three!)
~ Hendursaga
[1] https://people.umass.edu/klement/tlp/
^ permalink raw reply [relevance 4%]
* Re: Create in Org a bilingual book with facing pages
@ 2022-09-27 16:50 11% ` Juan Manuel Macías
2022-09-28 3:15 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-27 16:50 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi, Ihor, thanks for your comments.
Ihor Radchenko writes:
> This post appears to be a nice fit for
> https://orgmode.org/worg/org-blog-articles.html (except non-permanent
> imgur links). Do you have an Org version? Or maybe an actual blog post?
Precisely I have in mind to publish in my blog on typography
(https://lunotipia.juanmanuelmacias.com/) an extended and more detailed
version of this text, also including the function to which I refer (and
that I have not included in the post to the list for not making the text
any longer). The drawback is that my blog is in Spanish. I can easily
make an English version of the blog post as well. Who should I send the
link to, when I post it?
>> To compile the two PDFs separately and get the PDF in sync, I also do it
>> from Org using a shell source block. So I have all PDFs always
>> synchronized up to date. The synchronized PDF is obtained with pdftk:
>>
>> <https://i.imgur.com/qbSg2po.png>
>
> I notice two things here:
>
> 1. \clearpage command, which reminds me about
> https://orgmode.org/list/87mtamjrft.fsf@localhost
> May it be useful to have page break syntax element in Org?
I really don't have an opinion at the moment... As a user I try to put
as few direct LaTeX commands as possible: commands like \newpage,
\pagebreak, \clearpage, \bigskip, \quad, etc. Whenever I can, I
prefer to control spaces and page breaks using more general macros. And,
when I put these commands, the fact of resorting to an export snippet
does not usually bother me, since they are not very verbose commands.
But I don't know what other users will think...
> 2. You had to use direct LaTeX for caption. Can we do something to make
> the #+caption keywords more useful?
Yes, I use direct LaTeX in that case because I need to put the command
\caption*, the starred version of \caption provided by the caption
package. And before \caption*, I wanted to also add a \captionsetup. For
those cases, I think the :caption attribute already does a good job.
What would be interesting (IMO) is to be able to introduce arbitrary code
within the figure environment through an attribute, but this is where
the possible :export_template attribute could come into play, as we
discussed in the other thread.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: Create in Org a bilingual book with facing pages
2022-09-27 16:50 11% ` Juan Manuel Macías
@ 2022-09-28 3:15 5% ` Ihor Radchenko
2022-09-28 7:50 9% ` Explicit page breaks (was: Create in Org a bilingual book with facing pages) Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-09-28 3:15 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> This post appears to be a nice fit for
>> https://orgmode.org/worg/org-blog-articles.html (except non-permanent
>> imgur links). Do you have an Org version? Or maybe an actual blog post?
>
> Precisely I have in mind to publish in my blog on typography
> (https://lunotipia.juanmanuelmacias.com/) an extended and more detailed
> version of this text, also including the function to which I refer (and
> that I have not included in the post to the list for not making the text
> any longer).
Sounds good.
> The drawback is that my blog is in Spanish. I can easily
> make an English version of the blog post as well. Who should I send the
> link to, when I post it?
We already link to some non-English talks about Org.
It is just a matter of indicating the language near the WORG link.
Having both English and Spanish will be even better.
To add your blog article link to WORG, you can just make a patch against
https://git.sr.ht/~bzg/worg/tree/master/item/org-blog-articles.org
>> 1. \clearpage command, which reminds me about
>> https://orgmode.org/list/87mtamjrft.fsf@localhost
>> May it be useful to have page break syntax element in Org?
>
> I really don't have an opinion at the moment... As a user I try to put
> as few direct LaTeX commands as possible: commands like \newpage,
> \pagebreak, \clearpage, \bigskip, \quad, etc. Whenever I can, I
> prefer to control spaces and page breaks using more general macros. And,
> when I put these commands, the fact of resorting to an export snippet
> does not usually bother me, since they are not very verbose commands.
> But I don't know what other users will think...
Fine-tuning commands should indeed be dedicated to specific export
backends. It is generally meaningless to have \clearpage in html export.
However, \pagebreak specifically is something people use in plain text
files, and it may be useful for odt exports.
>> 2. You had to use direct LaTeX for caption. Can we do something to make
>> the #+caption keywords more useful?
>
> Yes, I use direct LaTeX in that case because I need to put the command
> \caption*, the starred version of \caption provided by the caption
> package. And before \caption*, I wanted to also add a \captionsetup. For
> those cases, I think the :caption attribute already does a good job.
> What would be interesting (IMO) is to be able to introduce arbitrary code
> within the figure environment through an attribute, but this is where
> the possible :export_template attribute could come into play, as we
> discussed in the other thread.
:export_template will indeed work for LaTeX. What I am looking for here
is some useful functionality that may be generalized to multiple export
backends.
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 5%]
* Re: Create in Org a bilingual book with facing pages
2022-09-27 16:34 4% ` Create in Org a bilingual book with facing pages Hendursaga
@ 2022-09-28 6:14 5% ` Juan Manuel Macías
2022-09-28 14:14 5% ` Hendursaga
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-28 6:14 UTC (permalink / raw)
To: Hendursaga; +Cc: orgmode
Hi, thank you for your comments.
Hendursaga writes:
>> The bilingual critical edition (ancient Greek/Spanish) of the
>> letters of Demosthenes and Aeschines has recently been published in
>> Spain, a book whose production and typesetting I have taken charge
>> of, using Org and Org-publish.
> What is the name of this book / the publisher's page? I don't really
> know Spanish, and only a little Greek, but I'm fascinated by bilingual
> editions, especially with critical apparati. I've been looking for a
> workflow for creating my own (possibly critical) bilingual works, but
> so far, months later, I haven't really found anything satisfactory.
Demóstenes y Esquines, Cartas atribuidas. Publisher: Dykinson.
Perhaps it is not yet in the catalog, because the book is very recent.
On this page you can see other critical editions (among other books)
that I have produced:
https://maciaschain.gitlab.io/lunotipia/muestra_trabajos.html. Certainly
critical editions are some of the most fascinating kinds of books out
there. My favorites are the Oxford Classical Texts, the Budé Collection,
and Teubner. In bilingual format the Loeb Classical Texts are also
excellent. All these have marked a canon.
>> First of all, for this kind of work you have to take into account an
>> inherent limitation of TeX: the compilation process in TeX is a
>> single-threaded process. That is, in TeX you cannot compile
>> different parts of a document, with different configurations (=
>> different preambles), at the same time.
>
> To clarify: you mean that you would have to have two distinct
> documents so that, say, the page titles, fonts, indices, etc can be
> specific to that "language half" of a work? I would've thought you
> could just have everything in one document. That's how I've been
> (trying to) do it so far, using the reledpar package, an extension of
> reledmac. Did you / have you tried using that? I've also tried various
> other packages, like the parallel package.
I think that the automatic synchronization of the facing pages of a
bilingual editions, either in TeX or in any other software, is a utopia.
Or, to be less radical and pessimistic, that is something possible in
very few scenarios. The ideal scenario would be for text A and text B to
have *exactly* the same number of lines and the same content per page.
This rarely happens. When it comes to poetry in verse it is more common
to happen. But factors such as the corpus of footnotes or the critical
apparatus, which are parts of the page with a variable height, also have
an influence. In the case of this book there was a significant gap
between the two texts. That is to say, that in the end a manual
intervention is necessary to balance the pages according to the content.
In the case of TeX/LaTeX, the single-thread TeX limitation is also
added. Packages like parallel (or paracol, which is newer) work fine
when dealing with simple text. At more complexity they are unusable. And
furthermore, in this case text A is a critical edition that needs its
own configuration. Parallel or paracol simply don't work here.
The case of reledpar could be the solution (since it is a version of
reledmac for parallel texts), but, unfortunately, it almost never is.
Reledpar works fine (more or less) when the scenario I mentioned at the
beginning occurs: if text A and text B are almost identical in length
page to page and paragraph to paragraph. Otherwise, manual
synchronization becomes very difficult and reledpar has a very erratic
behavior. Reledmac is wonderful, but I think reledpar is not a good
package and my recommendation is to avoid using it if possible.
As I said at the beginning, the ideal in TeX/LaTeX would be to be able
to compile with true parallel threads of text with a different
configuration, which is impossible. So my strategy is to create two
separate documents and load them with pdfpages. The good thing is that
Org helps a lot in this process, giving the feeling that I am working
with true parallel threads, since all the processes involved are
asynchronous.
>> On the other hand, since in this book the content of the odd and
>> even pages is variable, the synchronization has been done per page,
>> so that the reader always obtains the same content on the odd and
>> even page when facing the open book. For the Greek document I used
>> the reledmac LaTeX package[...]
>
> I've looked at reledmac, and I agree, it is pretty sophisticated. Can
> you clarify which synchronization method(s) you use? If you do use
> reledpar, in section 6.2.2, it lists the different ways you can
> synchronize. Otherwise, could you try to explain in terms it uses?
You might also want to take a look at ekdosis, a new package for
critical editions. It is not as complete as reledmac (for now), but it
has some interesting features, such as the possibility of exporting to
TEI.
As for what you ask me about the synchronization, this one is visual. It
is inevitable, from what I said before. And I think it is also
necessary. No matter how sophisticated typographic software is, in the
end human intervention is always necessary for things like this, which
depend on content and not on form. And for things like correcting
typographic rivers and such. Maybe in the not too distant future we can
train an IA to do it, but at the moment TeX doesn't understand content
:-). Of course, this synchronization must be done when both texts are
already hypercorrected. It is enough to add some marks to the text,
indicating where to generate a cut. Reledmac has the \ledpb command for
it, which I have redefined like this:
\makeatletter
\renewcommand{\led@check@pb}{\xifinlist{\the\absline@num}{\l@prev@pb}{\clearpage}{}}
\makeatother
>> Once both PDFs are obtained and synchronized, they are loaded into
>> the master Org document using the pdfpages LaTeX package. Since it
>> was necessary to introduce in certain pages some commands specific
>> to each page, such as page styles, index entries or labels for
>> references, and to avoid having to load the pages one by one with
>> pdfpages commands, I wrote a function that obtains the number of
>> pages of the synchronized PDF (via mutool) and it does all that
>> work. [...]
>
> To clarify once more: when you introduce page-specific commands, is
> this in the original PDF documents that you generate, or are those,
> like, trimmed and then you add on the headers etc later, or what?
Page-specific commands (such as page styles, reference labels, and so
on) are not in the original PDFs but are passed through the pdfpages
package, using the 'pagecommand' key. For example, with PDF pages you
can put something like (for page 1):
\includepdf[pages={1},noautoscale=true,pagecommand={\thispagestyle{empty}\label{foo}]{file.pdf}
What my function does is get the number of pages in the PDF and do all
that work, adding the commands I want on the needed page.
>> And that’s it. The next challenge for this fall is going to be a
>> trilingual edition of the New Testament (Greek, Latin, Spanish).
>> [...]
>
> Are you aware of Kevin Klement's trilingual edition[1] of
> Wittgenstein's Tractatus Logico-Philosophicus? (OK, it's technically
> bilingual, but with two separate English translations along with the
> original German!) He uses PHP (gross, I know!) to collate everything
> into a LaTeX document to then generate the various final versions.
> Besides the PHP, you might pick up a technique or two! (Or three!)
Interesting. For critical editions (among other text types for
Humanities), the standard for storing textual data is TEI
(https://en.wikipedia.org/wiki/Text_Encoding_Initiative). The problem
with TEI (at least for me) is that it consists of XML, and I hate XML
:-). In this regard, I think that a lightweight markup language as
powerful as Org could be a good alternative to TEI. And Org is indeed
human-readable. One could even think of a possible Org backend for
TEI...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 5%]
* Re: Create in Org a bilingual book with facing pages
2022-09-27 16:34 4% ` Create in Org a bilingual book with facing pages Hendursaga
@ 2022-09-28 7:14 7% ` Christian Moe
2 siblings, 0 replies; 200+ results
From: Christian Moe @ 2022-09-28 7:14 UTC (permalink / raw)
To: emacs-orgmode
Hi, Juan Manuel,
I keep saving your messages with process documentation for future
reference should I ever attempt anything similar. Much appreciated!
Yours,
Christian
Juan Manuel Macías writes:
> Hi all,
>
> TL; DR:
>
> The bilingual critical edition (ancient Greek/Spanish) of the letters of
> Demosthenes and Aeschines has recently been published in Spain, a book
> whose production and typesetting I have taken charge of, using Org and
> Org-publish. Although I already have a long experience typesetting
> bilingual editions of a certain complexity, especially for philological
> use, I had never done it until now by centralizing the entire process in
> Org-Mode. I have to say that it has been a very interesting experience,
> so I leave here below a brief description of the process and some tips,
> in case they can be useful to someone who wants to prepare from Org
> bilingual texts with facing pages and certain complexity.
>
> BTW, Here’s a sample of two pages from the book:
>
> <https://i.imgur.com/XUOGEnf.png>
>
> Long version:
>
> First of all, for this kind of work you have to take into account an
> inherent limitation of TeX: the compilation process in TeX is a
> single-threaded process. That is, in TeX you cannot compile different
> parts of a document, with different configurations (= different
> preambles), at the same time. For example, you cannot have one
> configuration for odd pages and another for even pages (original and
> translation) and compile them in parallel and asynchronously. In Adobe
> InDesign-style DTP programs you can load multiple page threads in
> parallel, but these programs don’t have the typographic refinement of
> TeX. And besides, I never use proprietary software ;-).
>
> Therefore, to create a bilingual edition with facing pages, and for this
> particular type of book where the odd pages (the text in Greek) is a
> critical edition with a strong critical apparatus
> (https://en.wikipedia.org/wiki/Critical_apparatus), it is necessary to
> compile two separate documents and then synchronize them. The good news:
> I have found that, thanks to Org, the process is much more streamlined
> and controlled.
>
> On the other hand, since in this book the content of the odd and even
> pages is variable, the synchronization has been done per page, so that
> the reader always obtains the same content on the odd and even page when
> facing the open book. For the Greek document I used the reledmac LaTeX
> package, which is the most mature LaTeX package for philological
> critical editions, but I used it through my org-critical-edition package
> (<https://gitlab.com/maciaschain/org-critical-edition>).
>
> Once both PDFs are obtained and synchronized, they are loaded into the
> master Org document using the pdfpages LaTeX package. Since it was
> necessary to introduce in certain pages some commands specific to each
> page, such as page styles, index entries or labels for references, and
> to avoid having to load the pages one by one with pdfpages commands, I
> wrote a function that obtains the number of pages of the synchronized
> PDF (via mutool) and it does all that work. The function has three
> arguments: the path to the synced PDF, the general page command, and a
> list of page numbers with particular commands (these last two arguments
> are optional). An example of use would be:
>
> ┌────
> │ (inserta-pdfpages-bi "resultado.pdf" "\\thispagestyle{plain}" '((2 "\\label{some-label}")))
> └────
>
> The function is evaluated in the master document within a source block:
>
> <https://i.imgur.com/yps6xRA.png>
>
> To compile the two PDFs separately and get the PDF in sync, I also do it
> from Org using a shell source block. So I have all PDFs always
> synchronized up to date. The synchronized PDF is obtained with pdftk:
>
> <https://i.imgur.com/qbSg2po.png>
>
> The rest of the book, introduction, indices, etc. it is normally done
> via Org publish. And the final compilation (the master document that
> includes all sub-documents) is done asynchronously using latexmk.
>
> And that’s it. The next challenge for this fall is going to be a
> trilingual edition of the New Testament (Greek, Latin, Spanish). My idea
> is to try to adapt to Org the use of the LaTeX package flowfram (an
> attempt to create dynamic indesign-style text boxes in LaTeX, but
> ---because of TeX's limitations--- they would not be asynchronous
> boxes). Then, each text in a language would go inside an org block.
> We'll see how it turns out :-)
>
> Best regards,
>
> Juan Manuel
>
> --
^ permalink raw reply [relevance 7%]
* Re: Re: Create in Org a bilingual book with facing pages
@ 2022-09-28 6:42 0% Pedro Andres Aranda Gutierrez
0 siblings, 0 replies; 200+ results
From: Pedro Andres Aranda Gutierrez @ 2022-09-28 6:42 UTC (permalink / raw)
To: Org Mode List
[-- Attachment #1: Type: text/plain, Size: 939 bytes --]
Ihor writes:
> Message: 12
> Date: Tue, 27 Sep 2022 20:29:25 +0800
> From: Ihor Radchenko <yantar92@gmail.com>
> To: Juan Manuel Macías <maciaschain@posteo.net>
> Cc: orgmode <emacs-orgmode@gnu.org>
> Subject: Re: Create in Org a bilingual book with facing pages
> Message-ID: <87bkr1ngpm.fsf@localhost>
> Content-Type: text/plain; charset=utf-8
>
>
> I notice two things here:
>
> 1. \clearpage command, which reminds me about
> https://orgmode.org/list/87mtamjrft.fsf@localhost
> May it be useful to have page break syntax element in Org?
I'm currently using the \clearpage too. So having a "native" element in ORG
may be superconvenient
Best, /PA
--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
[-- Attachment #2: Type: text/html, Size: 1630 bytes --]
^ permalink raw reply [relevance 0%]
* Explicit page breaks (was: Create in Org a bilingual book with facing pages)
2022-09-28 3:15 5% ` Ihor Radchenko
@ 2022-09-28 7:50 9% ` Juan Manuel Macías
2022-09-29 3:13 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-28 7:50 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>>> 1. \clearpage command, which reminds me about
>>> https://orgmode.org/list/87mtamjrft.fsf@localhost
>>> May it be useful to have page break syntax element in Org?
>>
>> I really don't have an opinion at the moment... As a user I try to put
>> as few direct LaTeX commands as possible: commands like \newpage,
>> \pagebreak, \clearpage, \bigskip, \quad, etc. Whenever I can, I
>> prefer to control spaces and page breaks using more general macros. And,
>> when I put these commands, the fact of resorting to an export snippet
>> does not usually bother me, since they are not very verbose commands.
>> But I don't know what other users will think...
>
> Fine-tuning commands should indeed be dedicated to specific export
> backends. It is generally meaningless to have \clearpage in html export.
>
> However, \pagebreak specifically is something people use in plain text
> files, and it may be useful for odt exports.
I agree. In the case of odt its xml is a pain for me to deal with, and
usually I have to open an odt document in Emacs and look at the
contents.xml file to find the (probably) correct tag Between that
hideous labyrinth of tags :-)
Well, considering that the most sensible place (IMO) to introduce an
explicit page break would be before almost anything that isn't a section
(since in sections page breaks should be defined by style), how about
something like this:
#+ATTR_LATEX: :pagebreak \clearpage
#+ATTR_ODT: :pagebreak t
Lorem ipsum dolor sit amet, consectetuer adipiscing elit...
(In the case of LaTeX the expected value of :pagebreak could be any of
several commands that LaTeX has for page breaking (or any other
arbitrary code). And if you put :pagebreak t, the default value would be
\pagebreak.
And to introduce an explicit break before a heading, the above could be
added as a property.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Create in Org a bilingual book with facing pages
2022-09-28 14:14 5% ` Hendursaga
@ 2022-09-28 15:14 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-28 15:14 UTC (permalink / raw)
To: Hendursaga; +Cc: orgmode
Hendursaga writes:
> I'll look through that page sometime! As for your favorites, I already
> have some of them on my lists, but I'll look at the others!
There are also the Renaissance editions, especially those by Aldo
Manuzio or Robert Estienne, which are true works of art. One of my free
time projects is trying to reproduce with LuaTeX an edition of Aldo
Manuzio (including the imperfections), but since I have less and less
free time in my life it is a project that is on the dead track
indefinitely :-)
> Have you done any works that are parallel / bilingual that parallel,
> paracol, or whatnot would probably be sufficient?
When I have tried to do something in real production with these packages
I have always had some problem. But I have done many tests with less
complex text and they do not work badly. Especially paracol, which is
based on multicol.
>> [...] For critical editions (among other text types for Humanities),
>> the standard for storing textual data is TEI
>> (https://en.wikipedia.org/wiki/Text_Encoding_Initiative). The
>> problem with TEI (at least for me) is that it consists of XML, and I
>> hate XML :-). In this regard, I think that a lightweight markup
>> language as powerful as Org could be a good alternative to TEI. And
>> Org is indeed human-readable. One could even think of a possible Org
>> backend for TEI...
>
> I also hate XML, but that's mostly when aiming for 100% compliance. A
> lot of features I really don't care for, and I really think the
> namespacing could've been much simpler, but with a superior editor
> like Emacs or perhaps a specialized one, I'd like to think much of the
> chore of TEI goes away..
Yeah, TEI has become, whether we like it or not, the standard for the
transmission of texts in the digital Humanities. Certainly a TEI-mode
for Emacs, or even a TEI backend for Org would be two wonderful things
if they existed. But I imagine it would also be a tremendous job to make
them exist :-)
> Question: have you looked at other (open-source) typesetting engines
> besides the TeX family? Like, say, *roff? In some ways, I prefer
> groff's way to TeX, but it being a much smaller community, with a much
> smaller ecosystem, gets in the way..
I did something with *roff, but it was a long time ago and nothing worth
remembering. I know *roff still has fans, and I remember seeing a
version out there that incorporates TeX's line break algorithms and has
support for opentype features. A kind of TeXroff, from what I
understand.
Most of my "typographical life" has revolved around TeX. But I entered
the world of TeX not through a standard TeX but through Omega, which was
an experimental version of TeX with Unicode support and a lot of very
sophisticated features, some of which not even LuaTeX has now by the
way, LuaTeX has taken a lot of ideas from Omega). Omega was fascinating,
but a horror to use. To install a TrueType font you had to go through a
few processes. Before using exclusively free software, I also used Adobe
Indesign quite a bit, and know it reasonably well. In fact InDesign has
also borrowed a lot from TeX.
Lately there have been some very interesting (and open source) projects
of new typesetting systems based on TeX but more modern. Among them, I
am very attracted to SILE (https://sile-typesetter.org/), and I have
played quite a lot with this system. It is written entirely in Lua and
supports multithreading. But this and other new projects have one major
problem (IMO): LaTeX. Or, rather, the absence of LaTeX. TeX and any
other typesetting system based on it is unusable as such. Its primitives
are a series of basic physical processes on the page. The good news is
that Knuth made TeX extensible (like Emacs) to be used through a
'format'. And LaTeX format, with its vast repertoire of macro packages,
has made TeX usable by a huge range of users. All those macro packages
are a job already done that nobody is going to be willing to do it
again. Therefore, I believe that any new typesetting system that is not
(in some way) compatible with LaTeX will unfortunately be doomed. The
alternative is that something modular and monolithic like ConTeXt might
emerge, but not with the richness and variety (sometimes excessive,
admittedly) of LaTeX.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: Create in Org a bilingual book with facing pages
2022-09-28 6:14 5% ` Juan Manuel Macías
@ 2022-09-28 14:14 5% ` Hendursaga
2022-09-28 15:14 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Hendursaga @ 2022-09-28 14:14 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> What is the name of this book / the publisher's page? I don't really know Spanish, and only a little Greek, but I'm fascinated by bilingual editions, especially with critical apparati. I've been looking for a workflow for creating my own (possibly critical) bilingual works, but so far, months later, I haven't really found anything satisfactory.
>
> Demóstenes y Esquines, Cartas atribuidas. Publisher: Dykinson.
>
> Perhaps it is not yet in the catalog, because the book is very recent.
Yeah, it doesn't appear to be in the catalog just yet. I'll look for it again sometime later!
> On this page you can see other critical editions (among other books) that I have produced: https://maciaschain.gitlab.io/lunotipia/muestra_trabajos.html. Certainly critical editions are some of the most fascinating kinds of books out there. My favorites are the Oxford Classical Texts, the Budé Collection, and Teubner. In bilingual format the Loeb Classical Texts are also excellent. All these have marked a canon.
I'll look through that page sometime! As for your favorites, I already have some of them on my lists, but I'll look at the others!
> I think that the automatic synchronization of the facing pages of a bilingual editions, either in TeX or in any other software, is a utopia.
I was beginning to think even state-of-the-art isn't sufficient yet :-/
> In the case of TeX/LaTeX, the single-thread TeX limitation is also added. Packages like parallel (or paracol, which is newer) work fine when dealing with simple text. At more complexity they are unusable. And furthermore, in this case text A is a critical edition that needs its own configuration. Parallel or paracol simply don't work here.
Have you done any works that are parallel / bilingual that parallel, paracol, or whatnot would probably be sufficient?
> You might also want to take a look at ekdosis, a new package for critical editions. It is not as complete as reledmac (for now), but it has some interesting features, such as the possibility of exporting to TEI.
Ah! I had that somewhere in my bookmarks; now that I have more knowledge on TEI, I might take a closer look! I would've thought importing TEI as opposed to exporting would be the easier / better way, though..
> [...] For critical editions (among other text types for Humanities), the standard for storing textual data is TEI (https://en.wikipedia.org/wiki/Text_Encoding_Initiative). The problem with TEI (at least for me) is that it consists of XML, and I hate XML :-). In this regard, I think that a lightweight markup language as powerful as Org could be a good alternative to TEI. And Org is indeed human-readable. One could even think of a possible Org backend for TEI...
I also hate XML, but that's mostly when aiming for 100% compliance. A lot of features I really don't care for, and I really think the namespacing could've been much simpler, but with a superior editor like Emacs or perhaps a specialized one, I'd like to think much of the chore of TEI goes away..
Question: have you looked at other (open-source) typesetting engines besides the TeX family? Like, say, *roff? In some ways, I prefer groff's way to TeX, but it being a much smaller community, with a much smaller ecosystem, gets in the way..
Cheers,
Hendursaga
^ permalink raw reply [relevance 5%]
* Re: org exported pdf files
@ 2022-09-28 18:23 12% ` Juan Manuel Macías
2022-09-29 20:58 6% ` Tim Cross
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-28 18:23 UTC (permalink / raw)
To: Tim Cross; +Cc: Timothy, Jude DaShiell, Ihor Radchenko, emacs-orgmode
Hi, Tim
Tim Cross writes:
> An unfortunate situation really - especially given Emacs has one of the
> most powerful and advanced accessibility options available via
> emacspeak.
>
> I also won't hold my breath for a new latgex core. THe latex3 initiative
> seems to have failed or at least appears to be slower to be realised than perl6!
You may find this article by Frank Mittelbach from 2020 interesting,
about the future of LaTeX and the challenges to be solved, including the
accessibility issues:
https://www.latex-project.org/publications/2020-FMi-TUB-tb128mitt-quovadis.pdf
On the other hand, there is also ConTeXt. I don't know much about
ConTeXt, but I remember reading somewhere that ConTeXt is more mature
than LaTeX on PDF tagging and accessibility issues. I don't know if
there are any ConTeXt experts on the list who can confirm this... In any
case, an ox-context already exists for org, written by Jason Ross.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: Explicit page breaks (was: Create in Org a bilingual book with facing pages)
2022-09-28 7:50 9% ` Explicit page breaks (was: Create in Org a bilingual book with facing pages) Juan Manuel Macías
@ 2022-09-29 3:13 5% ` Ihor Radchenko
2022-09-29 5:29 7% ` Explicit page breaks Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-09-29 3:13 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Well, considering that the most sensible place (IMO) to introduce an
> explicit page break would be before almost anything that isn't a section
> (since in sections page breaks should be defined by style), how about
> something like this:
>
> #+ATTR_LATEX: :pagebreak \clearpage
> #+ATTR_ODT: :pagebreak t
> Lorem ipsum dolor sit amet, consectetuer adipiscing elit...
>
> (In the case of LaTeX the expected value of :pagebreak could be any of
> several commands that LaTeX has for page breaking (or any other
> arbitrary code). And if you put :pagebreak t, the default value would be
> \pagebreak.
>
> And to introduce an explicit break before a heading, the above could be
> added as a property.
I do not like this idea.
Do note that page breaks may or may not lay between paragraphs or Org
elements. By its nature, page break is an object (in Org terminology).
I do understand your desire to allow putting page breaks before
headings. However, I think that proliferation of such export options is
a mistake. Instead, we should provide a generic way to define pre/post
text when exporting headings. We do discuss :export_templates in the
other thread, and we may as well define something similar but for
including the normal Org markup. (It should not be a property - I'd
rather have Org markup to be placed directly into the document and not
hidden inside properties drawer).
In any case, I'd rather discuss the question of putting staff prior to
exported heading in the :export_template thread.
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 5%]
* Re: Explicit page breaks
2022-09-29 3:13 5% ` Ihor Radchenko
@ 2022-09-29 5:29 7% ` Juan Manuel Macías
2022-09-29 6:21 4% ` Thomas S. Dye
2022-10-03 7:14 5% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-29 5:29 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Do note that page breaks may or may not lay between paragraphs or Org
> elements. By its nature, page break is an object (in Org terminology).
Indeed, page break can be placed anywhere. But inserting it before
paragraphs, at least in Org, is the least compromised by the
idiosyncrasies of each format: odt or LaTeX. And the most
format-agnostic. And on the other hand, in LaTeX and odt it's also the
safest place to put them, unless you want to add some fine-tuning in
either case.
Why would anyone want to add an explicit page break and interrupt the
natural flow of text on the page? It occurs to me that for two possible
reasons: a) for (let's say) "expressive" reasons, that is, because you
want certain content to start on a new page. And b) out of simple
necessity, to fix something you don't like: carry a line to the next
page, fix an overfull vbox in LaTeX, or a thousand other things.
Cuts by necessity can occur within the paragraph. But cutting a page
within a paragraph is a tricky thing. In libreoffice (and I think in any
word processor) you can place the cursor where you want to cut and press
control + enter. This creates a new page but also creates two
paragraphs, and we only want one paragraph, but with a page break in the
middle. I suppose that a forced line break should be added at the end of
the previous paragraph (and probably produce a very ugly result with
very wide spaces between words). But the section on the next page would
still be a new paragraph for libreoffice.
LaTeX is more refined, but the process and the caveats are the same.
\clearpage adds a new page (and a new paragraph) and terminates the old
one. And \pagebreak simply adds a page break (and the best place to add
it is between two paragraphs, I insist). If you have \flushbottom active
(by default in the book class), with \pagebreak LaTeX will do its best
to match the page height after \pagebreak, inserting the necessary
vertical space before the break. If you want to insert a page break
(\pagebreak) within a paragraph, LaTeX will choose the end of the line
to break. If you want to force the break exactly there, you'll probably
want to put something like \linebreak\par\pagebreak; again, you will now
find yourself with two paragraphs, and you will need to add at least one
\noindent before the second paragraph.
With all this, I mean: to what extent should Org care about all these
details, more related to fine-tuning the output format?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Explicit page breaks
2022-09-29 5:29 7% ` Explicit page breaks Juan Manuel Macías
@ 2022-09-29 6:21 4% ` Thomas S. Dye
2022-10-03 7:14 5% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Thomas S. Dye @ 2022-09-29 6:21 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ihor Radchenko, emacs-orgmode
Aloha all,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> Do note that page breaks may or may not lay between paragraphs
>> or Org
>> elements. By its nature, page break is an object (in Org
>> terminology).
>
> Indeed, page break can be placed anywhere. But inserting it
> before
> paragraphs, at least in Org, is the least compromised by the
> idiosyncrasies of each format: odt or LaTeX. And the most
> format-agnostic. And on the other hand, in LaTeX and odt it's
> also the
> safest place to put them, unless you want to add some
> fine-tuning in
> either case.
>
This doesn't reach to paragraphs, but tags do a good job of
inserting \clearpage and \newpage before a section heading in
LaTeX export.
****** Rasmus filter headline tags
This function was improved by Rasmus Pank Roulund based on one I
had
cobbled together from pieces posted on the Org mode mailing list.
#+name: rpr-filter-headline-tags
#+begin_src emacs-lisp :results silent
(defun tsd-filter-headline-tags (contents backend info)
"Ignore headlines with tag `ignoreheading' and/or start LaTeX
section with `newpage' or `clearpage' command."
(cond ((and (org-export-derived-backend-p backend 'latex)
(string-match "\\`.*newpage.*\n" (downcase contents))
;; if you want to get rid of labels use the string
;; "\\`.*ignoreheading.*\n.*\n"
(string-match "\\`.*ignoreheading.*\n" (downcase
contents)))
(replace-match "\\\\newpage\n" nil nil contents))
((and (org-export-derived-backend-p backend 'latex)
(string-match "\\`.*clearpage.*\n" (downcase contents))
(string-match "\\`.*ignoreheading.*\n" (downcase
contents)))
(replace-match "\\\\clearpage\n" nil nil contents))
((and (org-export-derived-backend-p backend 'latex 'html 'ascii)
(string-match "\\`.*ignoreheading.*\n" (downcase
contents)))
(replace-match "" nil nil contents))
((and (org-export-derived-backend-p backend 'latex)
(string-match
"\\(\\`.*?\\)\\(?:\\\\hfill{}\\)?\\\\textsc{.*?newpage.*?}\\(.*\n\\)"
(downcase contents)))
(replace-match "\\\\newpage\n\\1\\2" nil nil contents))
((and (org-export-derived-backend-p backend 'latex)
(string-match
"\\(\\`.*?\\)\\(?:\\\\hfill{}\\)?\\\\textsc{.*?clearpage.*?}\\(.*\n\\)"
(downcase contents)))
(replace-match "\\\\clearpage\n\\1\\2" nil nil contents))))
#+end_src
Hope this helps. If not, sorry for the noise.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
^ permalink raw reply [relevance 4%]
* Re: org exported pdf files
2022-09-28 18:23 12% ` Juan Manuel Macías
@ 2022-09-29 20:58 6% ` Tim Cross
0 siblings, 0 replies; 200+ results
From: Tim Cross @ 2022-09-29 20:58 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Timothy, Jude DaShiell, Ihor Radchenko, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi, Tim
>
> Tim Cross writes:
>
>> An unfortunate situation really - especially given Emacs has one of the
>> most powerful and advanced accessibility options available via
>> emacspeak.
>>
>> I also won't hold my breath for a new latgex core. THe latex3 initiative
>> seems to have failed or at least appears to be slower to be realised than perl6!
>
> You may find this article by Frank Mittelbach from 2020 interesting,
> about the future of LaTeX and the challenges to be solved, including the
> accessibility issues:
>
> https://www.latex-project.org/publications/2020-FMi-TUB-tb128mitt-quovadis.pdf
>
> On the other hand, there is also ConTeXt. I don't know much about
> ConTeXt, but I remember reading somewhere that ConTeXt is more mature
> than LaTeX on PDF tagging and accessibility issues. I don't know if
> there are any ConTeXt experts on the list who can confirm this... In any
> case, an ox-context already exists for org, written by Jason Ross.
>
> Best regards,
>
> Juan Manuel
>
> --
Thanks Juan, that is a useful link.
^ permalink raw reply [relevance 6%]
* Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals
@ 2022-10-02 13:47 13% ` Juan Manuel Macías
2022-10-03 4:23 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-02 13:47 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Fraga, Eric, Max Nikulin, emacs-orgmode@gnu.org
Ihor Radchenko writes:
> _name{<contents>}
> _name{{<contents>}} <--- extra {} is added as needed for escaping
> _name[:key value ...]{<contents>}
>
> The syntax idea is to follow the relevance between [[links]] and [cite:citations]
> but here we have src_name[...]{...} and _name[...]{<contents>} instead.
And how about this:
%_name{<contents>}
%_name{{<contents>}} <--- extra {} is added as needed for escaping
%_name[:key value ...]{<contents>}
or any other symbol instead of "%" ?
N.B.: I must admit this is more for an "aesthetic" reason. Although
perhaps it can be useful to search in the documents.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals
2022-10-02 13:47 13% ` Juan Manuel Macías
@ 2022-10-03 4:23 5% ` Ihor Radchenko
2022-10-04 20:28 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-10-03 4:23 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Fraga, Eric, Max Nikulin, emacs-orgmode@gnu.org
Juan Manuel Macías <maciaschain@posteo.net> writes:
> And how about this:
>
> %_name{<contents>}
> %_name{{<contents>}} <--- extra {} is added as needed for escaping
> %_name[:key value ...]{<contents>}
>
> or any other symbol instead of "%" ?
>
> N.B.: I must admit this is more for an "aesthetic" reason. Although
> perhaps it can be useful to search in the documents.
I have to admit that I am not a big fan of underscore in _name myself.
Just wanted to keep some resemblance of src_name{<contents>} yet not
making things too verbose (like block_name{<contents>}).
If I were to choose an alternative symbol other than "_", I'd choose
"@":
@name{<contents>}
@name{{<contents}}
@name[:key value ...]{<contents>}
1. It is similar to Texinfo
2. It does not clash with TeX
3. We already use @ in the inline export snippets.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Explicit page breaks
2022-09-29 5:29 7% ` Explicit page breaks Juan Manuel Macías
2022-09-29 6:21 4% ` Thomas S. Dye
@ 2022-10-03 7:14 5% ` Ihor Radchenko
2022-10-04 20:24 8% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-10-03 7:14 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> ...
> With all this, I mean: to what extent should Org care about all these
> details, more related to fine-tuning the output format?
Thanks for the detailed explanation!
It is now clear that pagebreak by itself may very much depend on the
specifics of the export backend and the place in the document.
Using page break at the same place for different export backends is
unlikely to be useful.
On the other hand, some backends (odt) are too cumbersome to put page
breaks within @@odt:...@@ export snippets.
What we do want is some way to put a page break just for odt or just for
latex.
May we introduce a new standard macro {{{page-break(backend)}}}
that will expand to an appropriate
@@backend:<whatever is needed to mark new page in the given backend@@
?
WDYT?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Explicit page breaks
2022-10-03 7:14 5% ` Ihor Radchenko
@ 2022-10-04 20:24 8% ` Juan Manuel Macías
2022-10-05 7:59 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-04 20:24 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> May we introduce a new standard macro {{{page-break(backend)}}}
> that will expand to an appropriate
> @@backend:<whatever is needed to mark new page in the given backend@@
> ?
The macro seems like a good idea. The only (minor) inconvenience that I
see, if I have understood it correctly, is in the case of LaTeX, where
there are several commands that do different things: \pagebreak,
\clearpage, \newpage, etc.
Since \pagebreak is a more low-level command (introduces a hard break),
it could be left as the default command \clearpage, which starts a new
page and ends the old one. I don't know...
By the way, in LaTeX there is also the opposite of \pagebreak:
\nopagebreak, with a mandatory level from 1 to 4. I see this type of
commands more useful for defining new LaTeX commands than for inserting
them directly into the document.
And, in any case, I think this page break topic is most useful
especially for odt, which only has a hard break (and also splits the
paragraph in two if added inside the paragraph). For LaTeX, after all,
putting things like @@latex:\pagrebreak[2]@@ doesn't involve much
verbosity.
Anyway, the opendocument schema is completely arcane to me. I have taken
a look at the Org Manual and it says that this snippet adds a page break
in odt export:
#+odt:<text:p text:style-name="PageBreak"/>
But I have tried:
foo
#+odt:<text:p text:style-name="PageBreak"/>
bar
and the document is not exported with the page break. I don't know if
I'm missing something. But as i said, XML is beyond me :-).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals
2022-10-03 4:23 5% ` Ihor Radchenko
@ 2022-10-04 20:28 10% ` Juan Manuel Macías
2022-10-05 6:56 5% ` Rick Lupton
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-04 20:28 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Fraga, Eric, Max Nikulin, emacs-orgmode@gnu.org
Ihor Radchenko writes:
> If I were to choose an alternative symbol other than "_", I'd choose
> "@":
>
> @name{<contents>}
> @name{{<contents}}
> @name[:key value ...]{<contents>}
>
> 1. It is similar to Texinfo
> 2. It does not clash with TeX
> 3. We already use @ in the inline export snippets.
I like the "@" alternative a lot. And I agree with all three points. It is
also compact without losing clarity, and does not give the feeling of a
blank space before, as in the case of "_".
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Explicit page breaks
2022-10-04 20:24 8% ` Juan Manuel Macías
@ 2022-10-05 7:59 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-10-05 7:59 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> May we introduce a new standard macro {{{page-break(backend)}}}
>> that will expand to an appropriate
>> @@backend:<whatever is needed to mark new page in the given backend@@
>> ?
>
> The macro seems like a good idea. The only (minor) inconvenience that I
> see, if I have understood it correctly, is in the case of LaTeX, where
> there are several commands that do different things: \pagebreak,
> \clearpage, \newpage, etc.
>
> Since \pagebreak is a more low-level command (introduces a hard break),
> it could be left as the default command \clearpage, which starts a new
> page and ends the old one. I don't know...
>
> By the way, in LaTeX there is also the opposite of \pagebreak:
> \nopagebreak, with a mandatory level from 1 to 4. I see this type of
> commands more useful for defining new LaTeX commands than for inserting
> them directly into the document.
Hmm... Then I am wondering about the utility of page break macro outside
odt export.
> And, in any case, I think this page break topic is most useful
> especially for odt, which only has a hard break (and also splits the
> paragraph in two if added inside the paragraph). For LaTeX, after all,
> putting things like @@latex:\pagrebreak[2]@@ doesn't involve much
> verbosity.
>
> Anyway, the opendocument schema is completely arcane to me. I have taken
> a look at the Org Manual and it says that this snippet adds a page break
> in odt export:
>
> #+odt:<text:p text:style-name="PageBreak"/>
>
> But I have tried:
>
> foo
>
> #+odt:<text:p text:style-name="PageBreak"/>
>
> bar
>
> and the document is not exported with the page break. I don't know if
> I'm missing something. But as i said, XML is beyond me :-).
I missed this part of the manual.
If adding page break is this easy, I am not sure if we really need to
bother with macro.
The only thing might be adding the PageBreak style into
etc/styles/OrgOdtStyles.xml, which you likely missed. (see *Hint* in the
manual).
Or we may also add {{{odt-page-break}}} macro for odt specifically.
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 5%]
* A function to perform Org related searches in several places
@ 2022-10-05 9:49 8% Juan Manuel Macías
2022-10-06 5:42 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-05 9:49 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
Hi all,
For my personal use I have written a function which performs Org related
searches in different places. The list of places is expandable, but so
far I found them useful: this mailing list, the Org Manual (via org-ql),
the Git log and the Org Reddit. The idea was that everything would be
done without leaving Emacs confort, so the results from the internet are
returned in EWW.
Before entering the search term, it defaults to the word at point or the
marked region.
The function has two versions. The first version does not depend on any
external packages to display the options. The second version includes a
simple hydra. The hydra version has the advantage that you can have the
hydra buffer open and continue running more searches on the same term. I
don’t know if it’s very orthodox to include the definition of the hydra
inside the function (I would say no, I don’t know), but I couldn’t think
of another way to pass the argument to the different heads of the hydra…
It’s homemade and improvable code, but I’m attaching it here in an Org
document, in case someone finds it useful :-).
Best regards,
Juan Manuel
[-- Attachment #2: function.org --]
[-- Type: application/vnd.lotus-organizer, Size: 2915 bytes --]
^ permalink raw reply [relevance 8%]
* Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals
2022-10-04 20:28 10% ` Juan Manuel Macías
@ 2022-10-05 6:56 5% ` Rick Lupton
0 siblings, 0 replies; 200+ results
From: Rick Lupton @ 2022-10-05 6:56 UTC (permalink / raw)
To: Y. E.
Hi Ihor and all,
I wonder if you have seen Pollen’s approach to this? https://docs.racket-lang.org/pollen/pollen-command-syntax.html
There are two separate ideas used there which seemed related to this discussion. I’m not sure if they are useful in the org context.
1. The use of a special character (◊ by default) which introduces a command/inline special block. I don’t know if this would be worth considering as an alternative to @ (which also seems reasonable) to avoid ambiguity with other syntax. As the link above discusses it’s harder to type but there are solutions.
2. Making it easy to define custom functions that produce org syntax. A bit like perhaps Max's suggestion to use source blocks, but instead of writing AST-like structure directly in the document where you want it, you can call a previously defined function to build it. This is similar to org macros but I’m not sure if they are so flexible as a lisp function. There is also the option to choose between passing arguments as lisp (in [ ]) or as markup (in { })
On Tue, 4 Oct 2022, at 9:28 PM, Juan Manuel Macías wrote:
> Ihor Radchenko writes:
>
>> If I were to choose an alternative symbol other than "_", I'd choose
>> "@":
>>
>> @name{<contents>}
>> @name{{<contents}}
>> @name[:key value ...]{<contents>}
>>
>> 1. It is similar to Texinfo
>> 2. It does not clash with TeX
>> 3. We already use @ in the inline export snippets.
>
> I like the "@" alternative a lot. And I agree with all three points. It is
> also compact without losing clarity, and does not give the feeling of a
> blank space before, as in the case of "_".
>
> Best regards,
>
> Juan Manuel
^ permalink raw reply [relevance 5%]
* Re: A function to perform Org related searches in several places
2022-10-05 9:49 8% A function to perform Org related searches in several places Juan Manuel Macías
@ 2022-10-06 5:42 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-10-06 5:42 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> For my personal use I have written a function which performs Org related
> searches in different places. The list of places is expandable, but so
> far I found them useful: this mailing list, the Org Manual (via org-ql),
> the Git log and the Org Reddit. The idea was that everything would be
> done without leaving Emacs confort, so the results from the internet are
> returned in EWW.
>
> Before entering the search term, it defaults to the word at point or the
> marked region.
I am using helm source for similar purposes.
The advantage is displaying live results.
I use Info search + helm-org-ql + live git query + notmuch query for the
mailing list.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Interest in an Org video meetup?
@ 2022-10-06 20:09 10% ` Juan Manuel Macías
2022-10-06 21:06 6% ` Russell Adams
2022-10-07 1:43 6% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-06 20:09 UTC (permalink / raw)
To: Russell Adams; +Cc: orgmode
Russell Adams writes:
> Would there be any interest in a monthly 1-2 hour long ad-hoc screen
> sharing and video discussion for Org-mode?
>
> I'm offering to schedule and moderate the first few events. I'd
> propose a Saturday meeting in the afternoon European time to cover EU
> and NA.
>
> I'm considering using Jitsi, or maybe GNU Jami.
>
> Topics could include Q&A, demonstrations of features, interactive
> troubleshooting, etc. I hadn't considered presentations, but
> that could be an option too.
>
> Comments?
Great idea. I would like to participate, even if it was just to listen
:-) But I'm afraid that these months I'm going to have horrible
schedules. Is it planned to record these meetings?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Interest in an Org video meetup?
2022-10-06 20:09 10% ` Juan Manuel Macías
@ 2022-10-06 21:06 6% ` Russell Adams
2022-10-07 1:43 6% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Russell Adams @ 2022-10-06 21:06 UTC (permalink / raw)
To: orgmode
On Thu, Oct 06, 2022 at 08:09:44PM +0000, Juan Manuel Macías wrote:
> Russell Adams writes:
>
> > Would there be any interest in a monthly 1-2 hour long ad-hoc screen
> > sharing and video discussion for Org-mode?
>
> Great idea. I would like to participate, even if it was just to listen
> :-) But I'm afraid that these months I'm going to have horrible
> schedules. Is it planned to record these meetings?
I can't commit to recording initially. I can't run them forever
either, but I'm happy to start the ball rolling.
Perhaps recording in the future?
------------------------------------------------------------------
Russell Adams RLAdams@AdamsInfoServ.com
https://www.adamsinfoserv.com/
^ permalink raw reply [relevance 6%]
* Re: Interest in an Org video meetup?
2022-10-06 20:09 10% ` Juan Manuel Macías
2022-10-06 21:06 6% ` Russell Adams
@ 2022-10-07 1:43 6% ` Ihor Radchenko
2022-10-07 1:47 0% ` Russell Adams
2022-10-09 15:12 0% ` Jean Louis
1 sibling, 2 replies; 200+ results
From: Ihor Radchenko @ 2022-10-07 1:43 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Russell Adams, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Great idea. I would like to participate, even if it was just to listen
> :-) But I'm afraid that these months I'm going to have horrible
> schedules. Is it planned to record these meetings?
Even if there is a recording, where can we publish the recorded videos?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Interest in an Org video meetup?
2022-10-07 1:43 6% ` Ihor Radchenko
@ 2022-10-07 1:47 0% ` Russell Adams
2022-10-07 10:37 13% ` Juan Manuel Macías
2022-10-09 15:12 0% ` Jean Louis
1 sibling, 1 reply; 200+ results
From: Russell Adams @ 2022-10-07 1:47 UTC (permalink / raw)
To: orgmode
On Fri, Oct 07, 2022 at 09:43:23AM +0800, Ihor Radchenko wrote:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
> > Great idea. I would like to participate, even if it was just to listen
> > :-) But I'm afraid that these months I'm going to have horrible
> > schedules. Is it planned to record these meetings?
>
> Even if there is a recording, where can we publish the recorded videos?
Exactly.
Recording brings with it extra logistics, which is why I deferred the
issue. ;]
------------------------------------------------------------------
Russell Adams RLAdams@AdamsInfoServ.com
https://www.adamsinfoserv.com/
^ permalink raw reply [relevance 0%]
* Re: Interest in an Org video meetup?
2022-10-07 1:47 0% ` Russell Adams
@ 2022-10-07 10:37 13% ` Juan Manuel Macías
2022-10-07 12:06 6% ` Interest in an Org video meetup? George Mauer
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-07 10:37 UTC (permalink / raw)
To: Russell Adams; +Cc: orgmode, Ihor Radchenko
Russell Adams writes:
>> Even if there is a recording, where can we publish the recorded videos?
>
> Exactly.
>
> Recording brings with it extra logistics, which is why I deferred the
> issue. ;]
I was just asking, out of curiosity, if it was planned to be published.
I really don't know where it could be published. I know PeerTube exists,
but I don't know how it works.
There is the YouTube option, which I imagine no one would like (me
neither). The only thing in its favor is that Invidious can be used to
watch the videos. BTW, I watch YT videos through Invidious in Emacs,
with the Ytel package and EMMS/MPV.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: Interest in an Org video meetup?
2022-10-07 10:37 13% ` Juan Manuel Macías
@ 2022-10-07 12:06 6% ` George Mauer
1 sibling, 0 replies; 200+ results
From: George Mauer @ 2022-10-07 12:06 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]
I would try to join.
One thing I always mention when conversations about recording come up is
that if you promote recordings as a resource, it is considered good form to
have transcription available. I'm pretty sure a community effort like this
world be under no ADA obligations (unlike company meetings) but still good
form.
On Fri, Oct 7, 2022, 05:45 Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Russell Adams writes:
>
> >> Even if there is a recording, where can we publish the recorded videos?
> >
> > Exactly.
> >
> > Recording brings with it extra logistics, which is why I deferred the
> > issue. ;]
>
> I was just asking, out of curiosity, if it was planned to be published.
> I really don't know where it could be published. I know PeerTube exists,
> but I don't know how it works.
>
> There is the YouTube option, which I imagine no one would like (me
> neither). The only thing in its favor is that Invidious can be used to
> watch the videos. BTW, I watch YT videos through Invidious in Emacs,
> with the Ytel package and EMMS/MPV.
>
> Best regards,
>
> Juan Manuel
>
> --
> --
> ------------------------------------------------------
> Juan Manuel Macías
>
> https://juanmanuelmacias.com
>
> https://lunotipia.juanmanuelmacias.com
>
> https://gnutas.juanmanuelmacias.com
>
>
[-- Attachment #2: Type: text/html, Size: 2033 bytes --]
^ permalink raw reply [relevance 6%]
* Re: watch YT videos through in Emacs [Was: Interest in an Org video meetup?]
@ 2022-10-07 13:17 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-07 13:17 UTC (permalink / raw)
To: Quiliro Ordóñez; +Cc: emacs-orgmode
Hola, Quirilo,
Quiliro Ordóñez writes:
>> There is the YouTube option, which I imagine no one would like (me
>> neither). The only thing in its favor is that Invidious can be used to
>> watch the videos. BTW, I watch YT videos through Invidious in Emacs,
>> with the Ytel package and EMMS/MPV.
>
> Nice. Is there a guide to do this specificly?
I have written a bunch of homemade hacks for ytel, including the ability
to display video thumbnails in the results. I explain all the details on
my blog, here:
https://gnutas.juanmanuelmacias.com/ytel_invidious.html
The post is in Spanish. If anyone is interested in this topic, I can
write a version in English.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [tip] Create and Insert a public Nextcloud/Owncloud link
@ 2022-10-08 14:29 7% Juan Manuel Macías
2022-10-09 3:32 6% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-08 14:29 UTC (permalink / raw)
To: orgmode
Hi all,
One of the few things that I miss from a desktop environment like Gnome
Shell or KDE Plasma (currently I use EXWM), is the good integration
these environments had with Nextcloud, as I am a heavy user of
Nextcloud. Many times I need to create and share a public link to a file
in my local folder. In the Nextcloud forum I learned how it can be done
from the command line using curl, so starting from that, it wasn’t very
difficult to write this function in Elisp to insert a public link at
point. It can be inserted in two ways: literally or as an Org bracket
link, with description.
For the function to work we must have: a) a folder within our local
Nextcloud directory dedicated exclusively to public files; b) a line
with our personal data in the ~/.authinfo file. Assuming, for example,
that we use a third-party Nextcloud service like Disroot, the necessary
line in authinfo would be:
machine cloud.disroot.org login <my-user-name> password <my-password>
And let’s go with the function. Before I have defined these three
variables:
┌────
│ (defvar nextcloud-url "https://cloud.disroot.org")
│ (defvar nextcloud-public-folder "~/disroot/Public/")
│ (defvar nextcloud-public-folder-name "Public")
└────
And the function itself (caveat: the function is not asynchronous):
┌────
│ (defun insert-nextcloud-link ()
│ (interactive)
│ (let* ((file-name (read-file-name "File: "
│ nextcloud-public-folder))
│ (file (if (directory-name-p
│ file-name)
│ (replace-regexp-in-string
│ (expand-file-name
│ nextcloud-public-folder)
│ ""
│ file-name)
│ (file-name-nondirectory file-name)))
│ (desc
│ (read-from-minibuffer
│ "Link description (enter = no description): "))
│ (auth
│ (nth 0
│ (auth-source-search
│ :host "cloud.disroot.org"
│ :requires '(user secret))))
│ (my-username (plist-get auth :user))
│ (my-passwd (funcall (plist-get auth :secret)))
│ (result-raw (shell-command-to-string
│ (concat "curl -u "
│ "\""
│ my-username
│ ":"
│ my-passwd
│ "\""
│ " -H \"OCS-APIRequest: true\" -X POST "
│ nextcloud-url
│ "/ocs/v1.php/apps/files_sharing/api/v1/shares -d path="
│ "\""
│ nextcloud-public-folder-name
│ "/"
│ file
│ "\""
│ " -d shareType=3"
│ " -d permissions=1")))
│ (result (with-temp-buffer
│ (insert result-raw)
│ (goto-char (point-min))
│ (re-search-forward "<url>" nil t)
│ (let ((desde (point)))
│ (re-search-forward "<" nil t)
│ (narrow-to-region desde (- (point) 1))
│ (buffer-string)))))
│ (if (string= desc "")
│ (insert result)
│ (insert (format "[[%s][%s]]" result desc)))))
└────
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Org and Hyperbole
@ 2022-10-08 20:34 6% ` Robert Weiner
2022-10-08 21:43 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Robert Weiner @ 2022-10-08 20:34 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]
Hi Juan:
I just tried your ':' technique for Hyperbole button activation with Avy
and it works well. But what is the advantage over just using Avy to jump
to the button and then pressing {M-RET}. With your technique, you have to
think about activating the button before you are there versus when you are
on it, as you normally do.
-- rsw
On Sat, Jun 25, 2022 at 10:32 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi, Robert,
>
> Robert Weiner writes:
>
> > We do like avy and as you say, Hyperbole can work with it. We try to
> > avoid requiring any non-builtin Emacs packages for Hyperbole. With a
> > few, we support them optionally. Unless there is a strong use case
> > for utilizing avy in certain ways, we would tend to leave that to
> > others to extend Hyperbole but personally I just add it in and use its
> > character and line navigation sometimes. Did you have any particular
> > uses in mind?
>
> My use of the mouse within Emacs is practically nonexistent, and outside
> of Emacs I have relegated the mouse to a few graphical applications such
> as Gimp, Krita, Scribus, and little else. That's why I find avy
> extremely handy for quickly navigating through text. By adding an action
> to avy-dispatch-alist you can execute an arbitrary command once the
> cursor has jumped to its target. For example, I have put this for
> hyperbole in my init:
>
> (add-to-list 'avy-dispatch-alist '(?: . (lambda (pt)
> (goto-char pt)
> (hkey-either))))
>
> Thus, the typical action to activate a 'far' hyperbole button would be:
>
> 1. Call avy and insert a letter;
>
> 2. When avy's hints are displayed in the screen, I hit the colon key ":"
> and then the hint letter I want to go to (an implicit button, for
> example). And at the moment the associated action of that button is
> executed.
>
> For those of us who hardly use the mouse, it is really very practical,
> and I think maybe mentioning that tip might be nice in the hyperbole
> documentation.
>
> Best regards,
>
> Juan Manuel
>
[-- Attachment #2: Type: text/html, Size: 3067 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Org and Hyperbole
2022-10-08 20:34 6% ` Robert Weiner
@ 2022-10-08 21:43 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-08 21:43 UTC (permalink / raw)
To: Robert Weiner; +Cc: rswgnu, orgmode
Robert Weiner writes:
> Hi Juan:
>
> I just tried your ':' technique for Hyperbole button activation with
> Avy and it works well. But what is the advantage over just using Avy
> to jump to the button and then pressing {M-RET}. With your technique,
> you have to think about activating the button before you are there
> versus when you are on it, as you normally do.
Hi, Robert,
Thanks for your comment. I agree with what you say. I'm afraid this
action, as I proposed it, is impractical. The proof is that I haven't
used it too much :-). Avy also includes some factory keys where the
action is performed on the target without losing focus or cursor
position. For example, to copy a "distant" word and paste at point. This
would be a more reasonable use case. Taking inspiration from Avy's code
for these actions, I've defined this new version:
(add-to-list 'avy-dispatch-alist '(?: . (lambda (pt)
(goto-char pt)
(hkey-either)
(let ((dat (ring-ref avy-ring 0)))
(select-frame-set-input-focus
(window-frame (cdr dat)))
(select-window (cdr dat))
(goto-char (car dat))))))
Now hkey-either would run without losing the current focus and cursor
position. An example of use that occurs to me: for my translation of the
Odyssey into Spanish I have defined some implicit buttons that do the
following: if they are activated in a certain positions of the verse
(for example, at the beginning of the verse), it is shown in a temporary
postframe: a) the verse translated by me if the action is performed on
the original Greek verse and b) the original Greek verse if the action
is on the translated verse.
I think that is better seen in this short video:
https://cloud.disroot.org/s/4c7ZFCAPTercgMS
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [tip] Create and Insert a public Nextcloud/Owncloud link
2022-10-08 14:29 7% [tip] Create and Insert a public Nextcloud/Owncloud link Juan Manuel Macías
@ 2022-10-09 3:32 6% ` Max Nikulin
2022-10-09 12:21 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-10-09 3:32 UTC (permalink / raw)
To: emacs-orgmode
On 08/10/2022 21:29, Juan Manuel Macías wrote:
>
> Many times I need to create and share a public link to a file
> in my local folder. In the Nextcloud forum I learned how it can be done
> from the command line using curl,
..
> │ (result-raw (shell-command-to-string
> │ (concat "curl -u "
> │ "\""
> │ my-username
> │ ":"
> │ my-passwd
> │ "\""
Juan Manuel, your function is a nice proof of concept, but posting such
code you are responsible for users who may try to use it verbatim having
less experience with elisp.
Use at least `shell-quote-argument' (though it docstring has a link to
info "(elisp)Security Considerations"). Just adding quote characters is
unsafe. You may avoid non-alphanumeric characters in passwords and file
names for good reasons, but for other users a quote character may
dramatically change the executed command.
When TRAMP support is not necessary, arguments should be passed to
external binary as a list without intermediate shell command. I know,
Emacs does not have a convenience function with such calling convention
similar to `shell-command-to-string'.
I am almost sure that Emacs has a package to send HTTP POST requests
directly from elisp. Unsure it has convenient enough API (reasonable
default timeouts, etc.), but it should be safer for working with
peculiar file names and passwords stuffed with characters having special
meaning in shell. I admit that the code would be more verbose. It may
save you time for recovering you system from damage caused by unexpected
interpretation of a shell command.
^ permalink raw reply [relevance 6%]
* Re: [tip] Create and Insert a public Nextcloud/Owncloud link
2022-10-09 3:32 6% ` Max Nikulin
@ 2022-10-09 12:21 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-09 12:21 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
>> Many times I need to create and share a public link to a file
>> in my local folder. In the Nextcloud forum I learned how it can be done
>> from the command line using curl,
> ..
>> │ (result-raw (shell-command-to-string
>> │ (concat "curl -u "
>> │ "\""
>> │ my-username
>> │ ":"
>> │ my-passwd
>> │ "\""
>
> Juan Manuel, your function is a nice proof of concept, but posting
> such code you are responsible for users who may try to use it verbatim
> having less experience with elisp.
>
> Use at least `shell-quote-argument' (though it docstring has a link to
> info "(elisp)Security Considerations"). Just adding quote characters
> is unsafe. You may avoid non-alphanumeric characters in passwords and
> file names for good reasons, but for other users a quote character may
> dramatically change the executed command.
>
> When TRAMP support is not necessary, arguments should be passed to
> external binary as a list without intermediate shell command. I know,
> Emacs does not have a convenience function with such calling
> convention similar to `shell-command-to-string'.
>
> I am almost sure that Emacs has a package to send HTTP POST requests
> directly from elisp. Unsure it has convenient enough API (reasonable
> default timeouts, etc.), but it should be safer for working with
> peculiar file names and passwords stuffed with characters having
> special meaning in shell. I admit that the code would be more verbose.
> It may save you time for recovering you system from damage caused by
> unexpected interpretation of a shell command.
Maxim, you are right that the use of shell-quote-argument is preferable
in cases like these to avoid unexpected problems with filenames,
passwords, and so on. I try to use it almost always. If I don't use it
more often, it's either because I'm lazy (because of my way of naming
the files, I don't expect this type of problems) or because I think it's
unnecessary, although not 100% free of danger[1], as in this case. I'm not
saying my behavior is exemplary, I'm just saying what I tend to do. I
should probably always use shell-quote-argument. In this case, the
affected part of my function would perhaps look better like this:
(shell-command-to-string
(mapconcat #'shell-quote-argument
`("curl"
"-u"
,(format
"%s:%s"
my-user
my-password)
"-H"
"OCS-APIRequest:true"
"-X"
"POST"
,(format
"%s/ocs/v1.php/apps/files_sharing/api/v1/shares"
nextcloud-url)
"-d"
,(format
"path=%s/%s"
nextcloud-public-folder-name
file)
"-d"
"shareType=3"
"-d"
"permissions=1")
" "))
[1] I think that a problem in this context would not go beyond the fact
that the function simply did not work as expected.
Perhaps it would have been better to use call-process-shell-command,
instead of shell-command-to-string, and extract the resulting string
from the output buffer.
On the other hand, I agree with you that whenever possible it is better
to use an Elisp solution than a shell command.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: Interest in an Org video meetup?
2022-10-07 1:43 6% ` Ihor Radchenko
2022-10-07 1:47 0% ` Russell Adams
@ 2022-10-09 15:12 0% ` Jean Louis
1 sibling, 0 replies; 200+ results
From: Jean Louis @ 2022-10-09 15:12 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Juan Manuel Macías, Russell Adams, orgmode
* Ihor Radchenko <yantar92@gmail.com> [2022-10-07 04:43]:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
> > Great idea. I would like to participate, even if it was just to listen
> > :-) But I'm afraid that these months I'm going to have horrible
> > schedules. Is it planned to record these meetings?
>
> Even if there is a recording, where can we publish the recorded videos?
Publish on https://joinpeertube.org/ that is fully free server software.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
^ permalink raw reply [relevance 0%]
* Information about all LaTeX packages in an Org document
@ 2022-10-10 15:19 10% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-10 15:19 UTC (permalink / raw)
To: orgmode
Hi all,
For my personal use I have created an Org document with the
bibliographic information of all the LaTeX packages currently in CTAN. I
have imported the data using org-bibtex-import-from-file. And I have
applied some further edits. The original data source is at:
https://www.ctan.org/pkg/ctan-bibdata
I think that in Org format this will be useful for me to access the
fields (properties) or manipulate them in various ways. In case someone
finds it useful too, it can be downloaded from here:
https://cloud.disroot.org/s/Qc9NLgPjXRJ29ya
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: idea for capture anywhere in x
@ 2022-10-11 9:11 9% ` Juan Manuel Macías
2022-10-12 1:09 5% ` Samuel Wales
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-11 9:11 UTC (permalink / raw)
To: Jean Louis; +Cc: emacs-orgmode
Jean Louis writes:
> Did you try to invoke Emacs without having Emacs in front of you? Once
> you try, come back and tell me how would you capture anything from X
> selection into Emacs without having Emacs window in front of you.
>
> I do not know how. My thinking stops right there.
>
> I have four workspaces, Emacs is not on each of them.
>
> How do I invoke Emacs without having it in front of me with just 1 key
> binding?
One solution is to let Emacs be your X window manager. I'm not saying
it's "the solution" to what's being discussed in this thread (sorry for
the noise), but in my case it is. With EXWM I don't need, for example,
anything like org-protocol. Even if I want to copy/cut/paste something
inside X, I have these three simultation keys defined in EXWM:
([?\C-y] . [?\C-v])
([?\C-w] . [?\C-x])
([?\M-w] . [?\C-c])
and I can use C-y, C-w or M-w in LibreOffice, Gimp or wherever.
One more example. If I'm in the external browser I normally use when I'm
not using eww (qutebrowser), I have a simple Org-capture template to
copy a url and create an Org heading with the link. I just hit yy on
qutebrowser and, without leaving there, call org-capture (C-c c). I have
another template to download images with org-download; another to create
a heading with the information extracted from google-scholar, etc. I
mean that using EXWM these problems don't exist, because, one way or
another, you're always in Emacs.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: idea for capture anywhere in x
2022-10-11 9:11 9% ` Juan Manuel Macías
@ 2022-10-12 1:09 5% ` Samuel Wales
0 siblings, 0 replies; 200+ results
From: Samuel Wales @ 2022-10-12 1:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Jean Louis, emacs-orgmode
fools [me] rush in where angels dare to tread, but
> Did you try to invoke Emacs without having Emacs in front of you? Once
> you try, come back and tell me how would you capture anything from X
i use the firefox org-capture extension. i click on a unicorn. url
and title are saved as an org link and any selected text.
emacs correctly does not end up in the wm's [fluxbox in my case] fg,
perhaps because of my org-capture settings. so i think i can say it
all works for firefox when the extension, which i adore, works.
incidentally all my applications are maximized or full screen for
accessibility reasons so anything popping up would be bad.
incidentally i always use kb or mouse for accessibility reasons and a
mixture does not work. i can't follow up to this discussion or engage
with you in a back and forth of any kind, just saying it works.
perhaps i misunderstood your challenge and post [reasonably likely].
the thread is about doing the same thing, or as much as possible of
it, more generally in x. for any application like an xterm, deluge,
maybe even emacs itself as an external to emacs buffer mode
independent facility. perhaps without requiring a firefox extension
even, although something would presumably have to grab the url and
title behind the scenes via .mozilla files or some hyopthetical
firefox api.
On 10/11/22, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Jean Louis writes:
>
>> Did you try to invoke Emacs without having Emacs in front of you? Once
>> you try, come back and tell me how would you capture anything from X
>> selection into Emacs without having Emacs window in front of you.
>>
>> I do not know how. My thinking stops right there.
>>
>> I have four workspaces, Emacs is not on each of them.
>>
>> How do I invoke Emacs without having it in front of me with just 1 key
>> binding?
>
> One solution is to let Emacs be your X window manager. I'm not saying
> it's "the solution" to what's being discussed in this thread (sorry for
> the noise), but in my case it is. With EXWM I don't need, for example,
> anything like org-protocol. Even if I want to copy/cut/paste something
> inside X, I have these three simultation keys defined in EXWM:
>
> ([?\C-y] . [?\C-v])
> ([?\C-w] . [?\C-x])
> ([?\M-w] . [?\C-c])
>
> and I can use C-y, C-w or M-w in LibreOffice, Gimp or wherever.
>
> One more example. If I'm in the external browser I normally use when I'm
> not using eww (qutebrowser), I have a simple Org-capture template to
> copy a url and create an Org heading with the link. I just hit yy on
> qutebrowser and, without leaving there, call org-capture (C-c c). I have
> another template to download images with org-download; another to create
> a heading with the information extracted from google-scholar, etc. I
> mean that using EXWM these problems don't exist, because, one way or
> another, you're always in Emacs.
>
> Best regards,
>
> Juan Manuel
>
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
^ permalink raw reply [relevance 5%]
* Re: watch YT videos through in Emacs [Was: Interest in an Org video meetup?]
@ 2022-10-12 10:22 9% ` Juan Manuel Macías
2022-10-12 10:52 6% ` Robert Weiner
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-12 10:22 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Quiliro Ordóñez, emacs-orgmode
Ihor Radchenko writes:
> Quiliro Ordóñez <quiliro@riseup.net> writes:
>
>> Hola Juan Manuel.
>>
>>> There is the YouTube option, which I imagine no one would like (me
>>> neither). The only thing in its favor is that Invidious can be used to
>>> watch the videos. BTW, I watch YT videos through Invidious in Emacs,
>>> with the Ytel package and EMMS/MPV.
>>
>> Nice. Is there a guide to do this specificly?
>
> I simply use
>
> #+begin_src bash :tangle ~/.local/bin/qutebrowser-call.sh :shebang #!/bin/bash
> URL="$1"
>
> if echo "$URL" | grep "youtube.com"; then
> # URL="$(echo "$URL" | sed -r 's/\\(www\\)?youtube\.com/invidious.namazso.eu/')"
> if [[ ! -z $(echo "$URL" | grep "/watch") ]]; then
> mpv $URL && exit;
> fi
> fi
>
> if echo "$URL" | grep "ted.com/talks"; then
> mpv $URL && exit;
> fi
>
> # if echo "$URL" | grep "reddit.com"; then
> # URL="$(echo "$URL" | sed -rE 's/www\.reddit\.com/libredd.it/')"
> # fi
>
> if echo "$URL" | grep "bilibili.com"; then
> mpv $URL && exit;
> fi
>
> grep "$URL" ~/.data/web-mirror/sources/* >/dev/null 2>&1 &&\
> ARCHIVE_DIR="$(echo "$URL" | archivebox-cmd list 2>/dev/null | tail -n1 | cut -d' ' -f1 | sed -r 's|/data|~/.data/web-mirror|')"
>
> if [[ ! -z "$ARCHIVE_DIR" ]]; then
> [[ -f "${ARCHIVE_DIR}/singlefile.html" ]] && URL="${ARCHIVE_DIR}/singlefile.html";
> fi
>
> #from https://github.com/qutebrowser/qutebrowser/blob/master/scripts/open_url_in_instance.sh
> _url="$URL"
> _command=":later 4000 :jump-mark last-position"
>
> qutebrowser "${_command}" ":spawn -u untrack-url -r -O ${_url}"
>
> #+end_src
>
> and my mpv is configured to use youtube-dl.
In this short video I show an example of my procedure to watch youtube
videos without leaving Emacs:
https://cloud.disroot.org/s/X3cfi2orT38CPyM
I use:
1. Helm-google-suggest (set to use duckduckgo)
2. Ytel (based on elfeed). With a few hacks that I have added, in order
to:
- Display thumbnails in the searches.
- Watch the video at point (via invidious) with EMMS/MPV,
configured with yt-dlp, which is a fork of youtube-dl that works
much better.
- Download the video at point with yt-dlp (full video or only audio)
- Create a bookmark of the video with org-capture
More info on my blog in Spanish (if anyone is interested, I can translate it):
https://gnutas.juanmanuelmacias.com/ytel_invidious.html
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: watch YT videos through in Emacs [Was: Interest in an Org video meetup?]
2022-10-12 10:22 9% ` Juan Manuel Macías
@ 2022-10-12 10:52 6% ` Robert Weiner
0 siblings, 0 replies; 200+ results
From: Robert Weiner @ 2022-10-12 10:52 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Ihor Radchenko, Quiliro Ordóñez, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2901 bytes --]
> More info on my blog in Spanish (if anyone is interested, I can
translate it)
Yes, please translate it to English.
-- rsw
On Wed, Oct 12, 2022 at 6:24 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Ihor Radchenko writes:
>
> > Quiliro Ordóñez <quiliro@riseup.net> writes:
> >
> >> Hola Juan Manuel.
> >>
> >>> There is the YouTube option, which I imagine no one would like (me
> >>> neither). The only thing in its favor is that Invidious can be used to
> >>> watch the videos. BTW, I watch YT videos through Invidious in Emacs,
> >>> with the Ytel package and EMMS/MPV.
> >>
> >> Nice. Is there a guide to do this specificly?
> >
> > I simply use
> >
> > #+begin_src bash :tangle ~/.local/bin/qutebrowser-call.sh :shebang
> #!/bin/bash
> > URL="$1"
> >
> > if echo "$URL" | grep "youtube.com"; then
> > # URL="$(echo "$URL" | sed -r 's/\\(www\\)?youtube\.com/
> invidious.namazso.eu/')"
> > if [[ ! -z $(echo "$URL" | grep "/watch") ]]; then
> > mpv $URL && exit;
> > fi
> > fi
> >
> > if echo "$URL" | grep "ted.com/talks"; then
> > mpv $URL && exit;
> > fi
> >
> > # if echo "$URL" | grep "reddit.com"; then
> > # URL="$(echo "$URL" | sed -rE 's/www\.reddit\.com/libredd.it/')"
> > # fi
> >
> > if echo "$URL" | grep "bilibili.com"; then
> > mpv $URL && exit;
> > fi
> >
> > grep "$URL" ~/.data/web-mirror/sources/* >/dev/null 2>&1 &&\
> > ARCHIVE_DIR="$(echo "$URL" | archivebox-cmd list 2>/dev/null | tail
> -n1 | cut -d' ' -f1 | sed -r 's|/data|~/.data/web-mirror|')"
> >
> > if [[ ! -z "$ARCHIVE_DIR" ]]; then
> > [[ -f "${ARCHIVE_DIR}/singlefile.html" ]] &&
> URL="${ARCHIVE_DIR}/singlefile.html";
> > fi
> >
> > #from
> https://github.com/qutebrowser/qutebrowser/blob/master/scripts/open_url_in_instance.sh
> > _url="$URL"
> > _command=":later 4000 :jump-mark last-position"
> >
> > qutebrowser "${_command}" ":spawn -u untrack-url -r -O ${_url}"
> >
> > #+end_src
> >
> > and my mpv is configured to use youtube-dl.
>
> In this short video I show an example of my procedure to watch youtube
> videos without leaving Emacs:
>
> https://cloud.disroot.org/s/X3cfi2orT38CPyM
>
> I use:
>
> 1. Helm-google-suggest (set to use duckduckgo)
>
> 2. Ytel (based on elfeed). With a few hacks that I have added, in order
> to:
>
> - Display thumbnails in the searches.
>
> - Watch the video at point (via invidious) with EMMS/MPV,
> configured with yt-dlp, which is a fork of youtube-dl that works
> much better.
>
> - Download the video at point with yt-dlp (full video or only audio)
>
> - Create a bookmark of the video with org-capture
>
> More info on my blog in Spanish (if anyone is interested, I can translate
> it):
>
> https://gnutas.juanmanuelmacias.com/ytel_invidious.html
>
> Best regards,
>
> Juan Manuel
>
>
[-- Attachment #2: Type: text/html, Size: 5516 bytes --]
^ permalink raw reply [relevance 6%]
* Re: idea for capture anywhere in x
@ 2022-10-12 14:22 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-12 14:22 UTC (permalink / raw)
To: Ypo; +Cc: Ihor Radchenko, bugs, Org-mode
Ypo writes:
> The first workflow would consist in emphasizing the web page
> permanently:
I think what you are looking for is something similar to what certain
extensions for firefox or chrome do, like highlighter. It's useful, but
I'd say only for static pages.
> 1. Open in ~eww~ the web page.
As long as the webpage doesn't (unfortunately) use javascript.
> 2. Emphasize with org-mode: highlight the text of the web page.
> 3. In the future, when opening again the web page, the highlights
> should appear.
It wouldn't be too hard (I think) to implement something for shr or eww,
so that overlays would be applied to highlight the text in eww-mode, and
the position info would be saved somewhere, so that eww would retrieve
it on page reload. As Ihor has recommended to you, org-remark could have
a (possible) use there. I would investigate on that side; also with
org-remark you could associate notes in org-mode.
> I don't know what would be the best way to do it. The only way I know
> similar to that, is using "org-web-tools-insert-web-page-as-entry".
It seems safer to me to save the content of a page in one way or
another, because that page may one day cease to be online. org-web-tools
is a great tool. The only drawback I find is that pandoc conversions
from html to org are not always very clean (depends on the page you want
to save). To the above could be added the possibility of highlighting
the content of the page and saving everything locally, to later read the
page offline in eww-mode.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Best android app
@ 2022-10-14 18:52 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-14 18:52 UTC (permalink / raw)
To: Renato Pontefice; +Cc: emacs-orgmode
Renato Pontefice writes:
> Sorry…I just realize that I’ve not tell for what I’m looking for the best application…. :-(
>
> It’s for open .org file!
> I would see my org-mode file I’ve created on my emacs on my Mac and check every things…
If you want to have a (more or less) complete Emacs/Org experience, my
recommendation is that you install Termux and install Emacs in Termux.
To get a working and updated version, better install it from F-droid.
There was a thread here recently about termux and org:
https://list.orgmode.org/87pmkfnh90.fsf@posteo.net/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Doubts about a function for my org-capture template
@ 2022-10-15 15:14 12% Juan Manuel Macías
2022-10-16 8:32 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-15 15:14 UTC (permalink / raw)
To: orgmode
Hi all,
I have written this function to be able to choose the type of block in
which to enclose the marked content (by default, quote). So in
my org-capture template I put %(my-capture-block) instead of %i:
┌────
│ (defun my-capture-block ()
│ (let ((initial (org-capture-get :initial)))
│ (when initial
│ (let ((block-name
│ (read-string
│ "Block type for marked content (default quote): "
│ nil nil "quote")))
│ (format
│ "#+begin_%s\n%s\n#+end_%s"
│ block-name
│ initial
│ (if (string-match "\\(src\\)\\(.+\\)" block-name)
│ (match-string 1 block-name)
│ block-name))))))
└────
The function works fine from eww, but it doesn't work with org-protocol
+ qutebrowser, as the value of :initial in org-capture-plist seems to be
nil. I've solved it by enclosing %i between two sexp %(...), one to
format the #+begin_xxx and the other to guess the #+end_xxx, but it's
more verbose. Does anyone have a clue how to get the value of %i for
org-protocol with a function inside the template?
Best regards and happy weekend,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX
@ 2022-10-15 21:35 11% Juan Manuel Macías
2022-10-16 3:24 5% ` Ihor Radchenko
2022-10-16 15:04 4% ` Max Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-15 21:35 UTC (permalink / raw)
To: orgmode
The recent addition of the `org-latex-line-break-safe' constant makes it
impossible to compile verse blocks. The reason is that now a \\ is
inserted between each stanza (aka each paragraph), instead of the
`\vspace{1em}' as before. That's wrong, as this compile error message
says:
---------
A \newline or \\ command appears between paragraphs, where it makes no
sense. If you're trying to ``leave a blank line'', use a \vspace
command.
---------
You can test yourself with this example:
#+begin_verse
lorem ipsum dolor
lorem ipsum dolor
lorem ipsum dolor
lorem ipsum dolor
lorem ipsum dolor
lorem ipsum dolor
#+end_verse
On the other hand, I have a few reservations about the usefulness of
org-latex-line-break-safe. To begin with, it is a particular solution
applied in a general way. This can have unexpected consequences, as has
happened in verse blocks. It's like putting your whole body in a
cast because of a broken finger.
I think if the reason for this addition is to prevent problems with
square brackets, in certain contexts, why not just apply a point
solution? For example, putting {[}, which is a common LaTeX way to
protect a square bracket. Use a macro, for example, or even
define a new entity, something like:
(setq org-entities-user
'(("lbrack" "{[}" nil "[" "[" "[" "[")
("rbrack" "{]}" nil "]" "]" "]" "]")))
And finally, I think that applying a general solution to this problem is
something that should be done(IMHO) in LaTeX and not in Org, for
example, with some new package that would protect certain signs or
through ad hoc LaTeX/Lua code.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: Best android app
@ 2022-10-15 23:01 6% ` Juan Manuel Macías
2022-10-16 0:57 6% ` Ypo
2022-10-17 18:01 5% ` Max Nikulin
1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-15 23:01 UTC (permalink / raw)
To: ypuntot; +Cc: Org-mode
ypuntot writes:
> https://easyorgmode.com/
Proprietary license. This should not be recommended here
(https://easyorgmode.com/terms).
^ permalink raw reply [relevance 6%]
* Re: Best android app
2022-10-15 23:01 6% ` Juan Manuel Macías
@ 2022-10-16 0:57 6% ` Ypo
2022-10-17 18:01 5% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Ypo @ 2022-10-16 0:57 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Org-mode
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
And I am reading that it is not for Android; just Linux, Windows and Mac.
Definitively, shouldn't go there.
El 16/10/2022 a las 1:01, Juan Manuel Macías escribió:
> ypuntot writes:
>
>> https://easyorgmode.com/
> Proprietary license. This should not be recommended here
> (https://easyorgmode.com/terms).
>
>
>
[-- Attachment #2: Type: text/html, Size: 1087 bytes --]
^ permalink raw reply [relevance 6%]
* Re: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX
2022-10-15 21:35 11% [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX Juan Manuel Macías
@ 2022-10-16 3:24 5% ` Ihor Radchenko
2022-10-16 12:08 4% ` Juan Manuel Macías
2022-10-16 15:04 4% ` Max Nikulin
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-10-16 3:24 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The recent addition of the `org-latex-line-break-safe' constant makes it
> impossible to compile verse blocks. The reason is that now a \\ is
> inserted between each stanza (aka each paragraph), instead of the
> `\vspace{1em}' as before. That's wrong, as this compile error message
> says:
Thanks for reporting!
Fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5fa66c7ffc4efbea11357fe0d05bc570855cfa91
This was an omission when replacing "\\" instances with safer version in
ox-latex.el.
> On the other hand, I have a few reservations about the usefulness of
> org-latex-line-break-safe. To begin with, it is a particular solution
> applied in a general way. This can have unexpected consequences, as has
> happened in verse blocks. It's like putting your whole body in a
> cast because of a broken finger.
The idea is to use "\\\someescapeLaTeXcommand" rather than "\\". The
latter can take arguments unexpectedly. See
https://orgmode.org/list/8735c0kpb9.fsf@localhost
> I think if the reason for this addition is to prevent problems with
> square brackets, in certain contexts, why not just apply a point
> solution? For example, putting {[}, which is a common LaTeX way to
> protect a square bracket.
Because people export tables not only to LaTeX, but also to other
formats. {[} makes no sense then.
> Use a macro, for example, or even
> define a new entity, something like:
>
> (setq org-entities-user
> '(("lbrack" "{[}" nil "[" "[" "[" "[")
> ("rbrack" "{]}" nil "]" "]" "]" "]")))
It will be unclear when to use such entity. Note that it is not obvious
at all that LaTeX export specifically will stumble on
| [1, 2] |
| [3, 4] |
without knowing LaTeX internals and checking the exported LaTeX
intermediate source closely.
We already ask users to deal with Org parser oddities. If we also demand
knowing LaTeX oddities, it will be too much. Better modify parser to
export valid Org syntax into valid LaTeX.
> And finally, I think that applying a general solution to this problem is
> something that should be done(IMHO) in LaTeX and not in Org, for
> example, with some new package that would protect certain signs or
> through ad hoc LaTeX/Lua code.
Either way, we will need to use the new package in ox-latex.el. And our
current approach is somewhat better because users can still use direct
LaTeX @@latex:\\@@ if they want to get "\\" exactly.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Doubts about a function for my org-capture template
2022-10-15 15:14 12% Doubts about a function for my org-capture template Juan Manuel Macías
@ 2022-10-16 8:32 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-10-16 8:32 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The function works fine from eww, but it doesn't work with org-protocol
> + qutebrowser, as the value of :initial in org-capture-plist seems to be
> nil.
Would you mind providing exact steps needed to reproduce the problem?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX
2022-10-16 3:24 5% ` Ihor Radchenko
@ 2022-10-16 12:08 4% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-16 12:08 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> And finally, I think that applying a general solution to this problem is
>> something that should be done(IMHO) in LaTeX and not in Org, for
>> example, with some new package that would protect certain signs or
>> through ad hoc LaTeX/Lua code.
>
> Either way, we will need to use the new package in ox-latex.el. And our
> current approach is somewhat better because users can still use direct
> LaTeX @@latex:\\@@ if they want to get "\\" exactly.
I'm afraid we differ completely on what Org's priorities are at this
point. The way I see it, Org shouldn't try to solve LaTeX problems,
because Org isn't proficient in LaTeX. This is a known issue in LaTeX,
where a leading bracket can be confused with the optional argument of a
preceding macro (such as \\ or \linebreak). And it doesn't just happen
in this context. It can also happen with environments that have optional
arguments, although the case of \\ is the most common and the case of
environments depends on how the environment is defined. For this
problem, LaTeX has been recommending various *specific* solutions
(because the probability of it appearing is very low, luckily), such as
enclosing the brackets in two {} or putting a \relax before .
In this case Org intends to solve the LaTeX problem, and it does it, in
my opinion, poorly, by generalizing a particular solution for what is
even an extremely rare problem. This is the typical case that can be
easily solved by the user with a macro or an export filter, as I have
been doing for a long time, and at no time have I needed anything else.
Org must worry about exporting well and offering the necessary tools for
that to happen, as it has been doing until now. And the duty of the
users is to know reasonably the language to which they export, to the
extent of what they want to obtain when they export. Org should not be a
substitute for LaTeX: whoever wants to get special things in LaTeX, must
know LaTeX. It's that easy. If Org is going to start trying to solve at
its own risk all the *specific* problems that can appear in the typical
compilation of a LaTeX document, then I prefer to stop using Org and use
pure LaTeX from the beginning.
And as for the ox-latex.el file, in its current state it is completely
unusable for me. At least the user could be offered the possibility of
choosing.
^ permalink raw reply [relevance 4%]
* Re: Best android app
@ 2022-10-16 12:13 6% ` Juan Manuel Macías
2022-10-16 12:32 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-16 12:13 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Jean Louis, Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Jean Louis <bugs@gnu.support> writes:
>
>> If I am not mistaken, you propose or initiate discussing how to list
>> proprietary software on some websites.
>>
>> GNU mailing lists are not for such discussions. GNU is project is
>> there to foster full free software.
>
> Do you know where this rule is documented?
Documented or undocumented, it's common sense. This is a mailing list of
the GNU project, and it is hoped that this list will not recommend the
use of unethical software that does not comply with the GNU philosophy.
^ permalink raw reply [relevance 6%]
* Re: Best android app
2022-10-16 12:13 6% ` Juan Manuel Macías
@ 2022-10-16 12:32 6% ` Ihor Radchenko
2022-10-16 13:14 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-10-16 12:32 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Jean Louis, Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> Jean Louis <bugs@gnu.support> writes:
>>
>>> If I am not mistaken, you propose or initiate discussing how to list
>>> proprietary software on some websites.
>>>
>>> GNU mailing lists are not for such discussions. GNU is project is
>>> there to foster full free software.
>>
>> Do you know where this rule is documented?
>
> Documented or undocumented, it's common sense. This is a mailing list of
> the GNU project, and it is hoped that this list will not recommend the
> use of unethical software that does not comply with the GNU philosophy.
Discussing and recommending are two different things.
Consider Windows. We do not recommend it. Yet, we do support it, and we
do discuss it.
WRT the Org apps, we are discussing things, and you are
trying to put stop on this discussion. I find it a bit too aggressive.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Best android app
2022-10-16 12:32 6% ` Ihor Radchenko
@ 2022-10-16 13:14 6% ` Juan Manuel Macías
2022-10-16 15:02 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-16 13:14 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Jean Louis, Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> WRT the Org apps, we are discussing things, and you are
> trying to put stop on this discussion. I find it a bit too aggressive.
What I have done is simply to remind that a specific application is not
free and should not be recommended here (the user who has cited that
application in good faith does not have to know it). That's exactly
discussing things.
Of course, I know the difference between discussing something and
recommending it.
And no, I do not intend what I have said to put stop a discussion. You
have added that by making a rather poor and out of place judgment of
intentions.
^ permalink raw reply [relevance 6%]
* Re: Best android app
2022-10-16 13:14 6% ` Juan Manuel Macías
@ 2022-10-16 15:02 6% ` Ihor Radchenko
2022-10-16 19:30 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-10-16 15:02 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Jean Louis, Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> WRT the Org apps, we are discussing things, and you are
>> trying to put stop on this discussion. I find it a bit too aggressive.
>
> What I have done is simply to remind that a specific application is not
> free and should not be recommended here (the user who has cited that
> application in good faith does not have to know it). That's exactly
> discussing things.
>
> Of course, I know the difference between discussing something and
> recommending it.
> And no, I do not intend what I have said to put stop a discussion. You
> have added that by making a rather poor and out of place judgment of
> intentions.
Clarification: I was actually referring to Jean's email. (I did not look
at the sender and just now realized that you are not Jean)
Having said that, my judgment may be still poor. I'd be happy to hear
that I am wrong from Jean.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX
2022-10-15 21:35 11% [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX Juan Manuel Macías
2022-10-16 3:24 5% ` Ihor Radchenko
@ 2022-10-16 15:04 4% ` Max Nikulin
2022-10-16 16:33 4% ` Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
2022-10-16 17:14 5% ` Line breaks and brackets in LaTeX export (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
1 sibling, 2 replies; 200+ results
From: Max Nikulin @ 2022-10-16 15:04 UTC (permalink / raw)
To: emacs-orgmode
On 16/10/2022 04:35, Juan Manuel Macías wrote:
>
> To begin with, it is a particular solution
> applied in a general way. This can have unexpected consequences, as has
> happened in verse blocks.
In my opinion Org has to apply a general solution merely because a table
may be result of evaluation of an org-babel code block. I may be wrong,
but I suspect that some users do not care what is the intermediate
format when they need a PDF file.
> And finally, I think that applying a general solution to this problem is
> something that should be done(IMHO) in LaTeX and not in Org,
Org has a bit more information concerning context of square brackets.
They may be just text of a table cell or contents of an export snippet.
In a LaTeX file they are just square brackets and there is no way to
distinguish them.
I believe, it is a design flaw in LaTeX that the \\ command does not
have a counterpart with no optional * and [] arguments. For humans \\ is
enough, but it is fragile when LaTeX is used as an intermediate export
format. A part of the problem is that all 3rd party packages should be
adapted for the robust \\ sibling. Likely it may be solved by additional
pass in the exporter code but it will significantly increase its
complexity. I have no idea what is appropriate place to discuss such
issue with LaTeX developers.
The following is irrelevant to the recent changes. I have tried
---- >8 ----
text
#+begin_verse
a b
c d
e f
g h
#+end_verse
---- 8< ----
With the fix Ihor committed today I have got
---- >8 ----
text
\begin{verse}
\vspace*{1em}
a b\\\empty
c d\\\empty
\vspace*{1em}
e f\\\empty
g h\\\empty
\end{verse}
---- 8< ----
My expectation was
---- >8 ----
\begin{verse}
a b\\\empty
c d
e f\\\empty
g h
\end{verse}
---- 8< ----
I am surprised that \vspace is added instead of empty line between
stanzas. Is there a reason to override LaTeX defaults? If such reason
exists would not it better to add
\parskip=1em plus 0.5em minus 0.25em\relax
before first verse line? Is hard coded rigid vertical space acceptable
when high quality output is desired? \vspace before first line looks
like a bug. Frankly speaking, nested calls of `replace-regexp-in-string'
makes the code hard to read.
P.S. I have not found exact citation, but I noticed a mention: Lamport
expected that verse environment would get negative feedback from poets.
^ permalink raw reply [relevance 4%]
* Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX)
2022-10-16 15:04 4% ` Max Nikulin
@ 2022-10-16 16:33 4% ` Juan Manuel Macías
2022-10-17 8:54 6% ` Ihor Radchenko
` (2 more replies)
2022-10-16 17:14 5% ` Line breaks and brackets in LaTeX export (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
1 sibling, 3 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-16 16:33 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> The following is irrelevant to the recent changes. I have tried
>
> ---- >8 ----
> text
>
> #+begin_verse
>
> a b
> c d
>
> e f
> g h
> #+end_verse
>
> ---- 8< ----
>
> With the fix Ihor committed today I have got
>
> ---- >8 ----
> text
> \begin{verse}
> \vspace*{1em}
> a b\\\empty
> c d\\\empty
> \vspace*{1em}
> e f\\\empty
> g h\\\empty
> \end{verse}
> ---- 8< ----
>
> My expectation was
> ---- >8 ----
> \begin{verse}
> a b\\\empty
> c d
>
> e f\\\empty
> g h
> \end{verse}
> ---- 8< ----
>
> I am surprised that \vspace is added instead of empty line between
> stanzas. Is there a reason to override LaTeX defaults? If such reason
> exists would not it better to add
>
> \parskip=1em plus 0.5em minus 0.25em\relax
>
> before first verse line? Is hard coded rigid vertical space acceptable
> when high quality output is desired? \vspace before first line looks
> like a bug. Frankly speaking, nested calls of `replace-regexp-in-string'
> makes the code hard to read.
>
> P.S. I have not found exact citation, but I noticed a mention: Lamport
> expected that verse environment would get negative feedback from poets.
First of all, I'm afraid that in my previous post I mixed up two
different issues: the verse block bug and my personal opinions about the
new added constant. I should have separated these topics, sorry.
I answer here what you comment about the verse blocks and later I will
open a different thread for the other issue.
Yes, you're right: that \vspace is the normal behavior of the block when
exporting to LaTeX, and it is certainly not quite correct. In LaTeX,
both the out-of-the-box verse environment and the one provided by the
'verse' package (which, typographically speaking, is the correct way to
represent verses in LaTeX) do not add a \vspace between stanzas. In the
LaTeX input the separation between stanzas is expressed by an (at least)
empty line. In fact, that space can be controlled by the verse package
with the stanzaskip \length. I remember that I commented on this anomaly
here on the list, a long time ago, but I can't find the original
message...
In my init I have redefined the verse block like this, so that there is
a white line between stanzas, not \vspace (I have also added some things
for the verse package, so that the numbering of verses is not broken).
So your example would produce a white line under \begin{verse}, not the
current \vspace, which would be irrelevant to LaTeX. But this is only a
hack:
(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."
(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}" "")))
(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 "%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
"\\(\\\\\\\\\n\\)+\\([ \t]*\\\\\\\\\\)+" "\n"
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n" "\\\\\n"
(setq contents
(if lin
(replace-regexp-in-string "\\(\n\\)+\\([ \t]*\n\\)+" "\\\\\\\\!\n\n"
contents)
contents)) nil t) nil t) nil t) linreset)
info)))
^ permalink raw reply [relevance 4%]
* Line breaks and brackets in LaTeX export (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX)
2022-10-16 15:04 4% ` Max Nikulin
2022-10-16 16:33 4% ` Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
@ 2022-10-16 17:14 5% ` Juan Manuel Macías
2022-10-17 9:04 5% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-16 17:14 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> In my opinion Org has to apply a general solution merely because a table
> may be result of evaluation of an org-babel code block. I may be wrong,
> but I suspect that some users do not care what is the intermediate
> format when they need a PDF file.
>
>> And finally, I think that applying a general solution to this problem is
>> something that should be done(IMHO) in LaTeX and not in Org,
>
> Org has a bit more information concerning context of square brackets.
> They may be just text of a table cell or contents of an export snippet.
> In a LaTeX file they are just square brackets and there is no way to
> distinguish them.
>
> I believe, it is a design flaw in LaTeX that the \\ command does not
> have a counterpart with no optional * and [] arguments. For humans \\ is
> enough, but it is fragile when LaTeX is used as an intermediate export
> format. A part of the problem is that all 3rd party packages should be
> adapted for the robust \\ sibling. Likely it may be solved by additional
> pass in the exporter code but it will significantly increase its
> complexity. I have no idea what is appropriate place to discuss such
> issue with LaTeX developers.
The solution of adding \relax or \empty is a good one. The problem is
when it is applied massively and indiscriminately, bearing in mind that
it is to prevent a problem that is, frankly, very rare. \empty is
unlikely to have any side effects, but still, I don't like Org making
these decisions for me and adding LaTeX code that I didn't ask for, in
form or quantity. Isn't it possible to be more selective, like Pandoc
does (I think), and add what needs to be added only when the problem is
present? I don't know if the Pandoc thing has already been mentioned in
past discussions, because these days I haven't been paying attention to
the list.
In any case, I would prefer: a) a selective solution; and if a) is not
possible, at least b) a defcustom.
This is an example I came up with of how it could be fixed selectively
in LaTeX (big, big caveat: it's just a proof of concept and likely to
produce errors in other contexts. I think if a LaTeX package to fix this
isn't already out, it is either because the problem is very rare and the
solution for particular cases is known, or because there are drawbacks
inherent to LaTeX that I can't figure out right now):
\makeatletter
\def\my@protectlbrack{
\@ifnextchar{[}{\relax}{}
\@ifnextchar{*}{\relax}{}
}
\let\old@break\\
\def\\{%
\old@break\my@protectlbrack}
%% for tables
\let\old@tabularcr\@tabularcr
\def\@tabularcr{%
\old@tabularcr\my@protectlbrack}
% for use the old commands
\newcommand\oldbreak{\old@break}
\newcommand\oldbreakt{\old@tabularcr}
\makeatother
\begin{document}
lorem\\
[ipsum]
lorem\\
*ipsum
\begin{tabular}{cccc}
a & a & a & a \\
[a] & a & a & a \\
*a & a & a & a \\
\end{tabular}
\end{document}
^ permalink raw reply [relevance 5%]
* Re: Best android app
2022-10-16 15:02 6% ` Ihor Radchenko
@ 2022-10-16 19:30 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-16 19:30 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Clarification: I was actually referring to Jean's email. (I did not look
> at the sender and just now realized that you are not Jean)
>
> Having said that, my judgment may be still poor. I'd be happy to hear
> that I am wrong from Jean.
Apologies for the misunderstanding. But in any case, I agree with what
Jean says. A GNU list is not the place to discuss whether proprietary
software should be recommended here or anywhere else. And I don't think
that affirming this (which is obvious) means aborting any possible
discussion. It is simply a reminder that such discussions should not
take place here. I don't think this is documented anywhere, but I insist
that it seems like common sense to me.
^ permalink raw reply [relevance 6%]
* Re: Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX)
2022-10-16 16:33 4% ` Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
@ 2022-10-17 8:54 6% ` Ihor Radchenko
2022-10-18 9:39 6% ` Verse block and separations Juan Manuel Macías
2022-10-17 14:48 7% ` Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Max Nikulin
2022-10-19 11:08 5% ` Max Nikulin
2 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-10-17 8:54 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Yes, you're right: that \vspace is the normal behavior of the block when
> exporting to LaTeX, and it is certainly not quite correct. In LaTeX,
> both the out-of-the-box verse environment and the one provided by the
> 'verse' package (which, typographically speaking, is the correct way to
> represent verses in LaTeX) do not add a \vspace between stanzas. In the
> LaTeX input the separation between stanzas is expressed by an (at least)
> empty line. In fact, that space can be controlled by the verse package
> with the stanzaskip \length. I remember that I commented on this anomaly
> here on the list, a long time ago, but I can't find the original
> message...
I checked git log and the current approach for verse export dates back
to initial versions of ox-latex. I am pretty sure that it should be
improved.
> In my init I have redefined the verse block like this, so that there is
> a white line between stanzas, not \vspace (I have also added some things
> for the verse package, so that the numbering of verses is not broken).
> So your example would produce a white line under \begin{verse}, not the
> current \vspace, which would be irrelevant to LaTeX. But this is only a
> hack:
Could you provide a patch?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Line breaks and brackets in LaTeX export (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX)
2022-10-16 17:14 5% ` Line breaks and brackets in LaTeX export (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
@ 2022-10-17 9:04 5% ` Ihor Radchenko
2022-10-17 11:30 7% ` Line breaks and brackets in LaTeX export Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-10-17 9:04 UTC (permalink / raw)
To: Juan Manuel Macías, Daniel Fleischer; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The solution of adding \relax or \empty is a good one. The problem is
> when it is applied massively and indiscriminately, bearing in mind that
> it is to prevent a problem that is, frankly, very rare. \empty is
> unlikely to have any side effects, but still, I don't like Org making
> these decisions for me and adding LaTeX code that I didn't ask for, in
> form or quantity. Isn't it possible to be more selective, like Pandoc
> does (I think), and add what needs to be added only when the problem is
> present? I don't know if the Pandoc thing has already been mentioned in
> past discussions, because these days I haven't been paying attention to
> the list.
>
> In any case, I would prefer: a) a selective solution; and if a) is not
> possible, at least b) a defcustom.
I tried to add the safe version of page break everywhere where there is
a risk of a page break followed by square brackets.
The key point: A valid Org file must be exported to a valid LaTeX file.
If you know a selective solution, patches are welcome. (I am also CCing
Daniel).
I see no issue with defcustom in general, but can you explain what
practical problems it is going to solve? I am not talking about
aesthetics of the exported LaTeX.
> This is an example I came up with of how it could be fixed selectively
> in LaTeX (big, big caveat: it's just a proof of concept and likely to
> produce errors in other contexts. I think if a LaTeX package to fix this
> isn't already out, it is either because the problem is very rare and the
> solution for particular cases is known, or because there are drawbacks
> inherent to LaTeX that I can't figure out right now):
>
> \makeatletter
>
> \def\my@protectlbrack{
> \@ifnextchar{[}{\relax}{}
> \@ifnextchar{*}{\relax}{}
> }
>
> \let\old@break\\
> \def\\{%
> \old@break\my@protectlbrack}
>
> %% for tables
>
> \let\old@tabularcr\@tabularcr
> \def\@tabularcr{%
> \old@tabularcr\my@protectlbrack}
>
> % for use the old commands
>
> \newcommand\oldbreak{\old@break}
> \newcommand\oldbreakt{\old@tabularcr}
>
> \makeatother
>
> \begin{document}
>
> lorem\\
> [ipsum]
>
> lorem\\
> *ipsum
>
> \begin{tabular}{cccc}
> a & a & a & a \\
> [a] & a & a & a \\
> *a & a & a & a \\
> \end{tabular}
>
>
> \end{document}
Won't it make it impossible to use
@@latex:\\@@
@@latex:[1em]@@
deliberately?
Note that we may also replace \\\empty with a single custom command. It
will look a bit cleaner. Not sure if it is any different from your
approach.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Line breaks and brackets in LaTeX export
2022-10-17 9:04 5% ` Ihor Radchenko
@ 2022-10-17 11:30 7% ` Juan Manuel Macías
2022-10-17 11:47 5% ` Ihor Radchenko
2022-10-17 15:01 11% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-17 11:30 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Daniel Fleischer, Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> I see no issue with defcustom in general, but can you explain what
> practical problems it is going to solve? I am not talking about
> aesthetics of the exported LaTeX.
In my opinion it is not so much a question of aesthetics as of (let's
say) a certain conformity with what a LaTeX document should be. I think,
for example, in the case of a user who must submit his/her work in LaTeX
format to a publication, following the rules of that publication. It is
one thing for a LaTeX document to compile without error and quite
another for a LaTeX document to be or not to be formed according to good
practice. Would there be a problem sharing LaTeX documents with
unnecessary commands like \empty after all occurrences of \\?
Anyway. As for the compilation, it is highly unlikely that \empty will
cause any unexpected error. But LaTeX and its over 6000 packages is
unpredictable. It also seemed unlikely that \relax would cause any
problems, and catching up on the last discussion, it had to be replaced
by \empty because it returned an error just before \hline. \relax is one
of the recommended solutions from LaTeX, because it tells LaTeX that the
previous macro has finished expanding, but it is recommended keeping in
mind that the user will apply it only when needed, not everywhere. And
before \hline it doesn't make sense because there will never be an
'\\[...]' error. So, in the current situation, we can ask ourselves: is
\empty everywhere safe? Everything points to yes. Can we be 100% sure?
...?
The only thing I can think of, for a non-selective solution like the
current one, is the following: if \\ has an optional argument that must
be a length, then let's give it, but with a value of zero: \\[0pt], which
is equivalent to putting the value by default (zero) explicitly.
>> This is an example I came up with of how it could be fixed selectively
>> in LaTeX (big, big caveat: it's just a proof of concept and likely to
>> produce errors in other contexts. I think if a LaTeX package to fix this
>> isn't already out, it is either because the problem is very rare and the
>> solution for particular cases is known, or because there are drawbacks
>> inherent to LaTeX that I can't figure out right now):
>>
>> \makeatletter
>>
>> \def\my@protectlbrack{
>> \@ifnextchar{[}{\relax}{}
>> \@ifnextchar{*}{\relax}{}
>> }
>>
>> \let\old@break\\
>> \def\\{%
>> \old@break\my@protectlbrack}
>>
>> %% for tables
>>
>> \let\old@tabularcr\@tabularcr
>> \def\@tabularcr{%
>> \old@tabularcr\my@protectlbrack}
>>
>> % for use the old commands
>>
>> \newcommand\oldbreak{\old@break}
>> \newcommand\oldbreakt{\old@tabularcr}
>>
>> \makeatother
>>
>> \begin{document}
>>
>> lorem\\
>> [ipsum]
>>
>> lorem\\
>> *ipsum
>>
>> \begin{tabular}{cccc}
>> a & a & a & a \\
>> [a] & a & a & a \\
>> *a & a & a & a \\
>> \end{tabular}
>>
>>
>> \end{document}
>
> Won't it make it impossible to use
> @@latex:\\@@
> @@latex:[1em]@@
>
> deliberately?
What I've done in this code is redefine \\ so that if the next character
is a [ or a * it doesn't do anything. To use the macro with the old
behavior, you would have to use the new macros \oldbreak and \oldbreakt
(this one for tables):
@@latex:\oldbreak@@
@@latex:[1em]@@
Anyway, like I said, it's a proof of concept. In the tests I've done it
works very well, but on a large scale I can't be sure of the results.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Line breaks and brackets in LaTeX export
2022-10-17 11:30 7% ` Line breaks and brackets in LaTeX export Juan Manuel Macías
@ 2022-10-17 11:47 5% ` Ihor Radchenko
2022-10-17 12:27 5% ` Juan Manuel Macías
2022-10-17 15:01 11% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-10-17 11:47 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Daniel Fleischer, Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> I see no issue with defcustom in general, but can you explain what
>> practical problems it is going to solve? I am not talking about
>> aesthetics of the exported LaTeX.
>
> In my opinion it is not so much a question of aesthetics as of (let's
> say) a certain conformity with what a LaTeX document should be. I think,
> for example, in the case of a user who must submit his/her work in LaTeX
> format to a publication, following the rules of that publication. It is
> one thing for a LaTeX document to compile without error and quite
> another for a LaTeX document to be or not to be formed according to good
> practice. Would there be a problem sharing LaTeX documents with
> unnecessary commands like \empty after all occurrences of \\?
I haven't seen any publication rule that prevents using valid LaTeX
commands like this. Do you have concrete examples? If not, one could
argue that any auto-generated output could break some imaginary rule.
I am also wondering how LaTeX documents generated from LyX or TeXmacs
look like. Are they not using some obvious machine-generated constructs?
> Anyway. As for the compilation, it is highly unlikely that \empty will
> cause any unexpected error. But LaTeX and its over 6000 packages is
> unpredictable. It also seemed unlikely that \relax would cause any
> problems, and catching up on the last discussion, it had to be replaced
> by \empty because it returned an error just before \hline. \relax is one
> of the recommended solutions from LaTeX, because it tells LaTeX that the
> previous macro has finished expanding, but it is recommended keeping in
> mind that the user will apply it only when needed, not everywhere. And
> before \hline it doesn't make sense because there will never be an
> '\\[...]' error. So, in the current situation, we can ask ourselves: is
> \empty everywhere safe? Everything points to yes. Can we be 100% sure?
> ...?
My answer is: "\\" is 100% not universally safe. Simply because we have
that bug report with [ ... ] items in tables.
So, anything with no concrete counter-example is better as long as we
are reasonably sure that we are not breaking LaTeX conventions.
> The only thing I can think of, for a non-selective solution like the
> current one, is the following: if \\ has an optional argument that must
> be a length, then let's give it, but with a value of zero: \\[0pt], which
> is equivalent to putting the value by default (zero) explicitly.
This has been proposed and then rejected by Max in
https://list.orgmode.org/orgmode/ti5tdb$rd2$1@ciao.gmane.io/ and he
concluded that some side effects are present when using \\[0pt]:
Max> \\[0pt]
Max>
Max> causes insertion of some code for negative vertical skip (of zero height
Max> this case). It should not be really harmful, but I would avoid this hack.
> What I've done in this code is redefine \\ so that if the next character
> is a [ or a * it doesn't do anything. To use the macro with the old
> behavior, you would have to use the new macros \oldbreak and \oldbreakt
> (this one for tables):
>
> @@latex:\oldbreak@@
> @@latex:[1em]@@
It means that LaTeX packages that redefine \\ may be affected. I'd
prefer to avoid such side effects.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Line breaks and brackets in LaTeX export
2022-10-17 11:47 5% ` Ihor Radchenko
@ 2022-10-17 12:27 5% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-17 12:27 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Daniel Fleischer, Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> I haven't seen any publication rule that prevents using valid LaTeX
> commands like this. Do you have concrete examples? If not, one could
> argue that any auto-generated output could break some imaginary rule.
No, I don't have any concrete example. But it is one thing to use a
valid LaTeX command and another to use it unnecessarily. It's like
putting \vspace{0pt} between each paragraph.
> I am also wondering how LaTeX documents generated from LyX or TeXmacs
> look like. Are they not using some obvious machine-generated constructs?
I don't know, because I haven't seen them. But I'd bet (at the risk of
losing the bet) that none of those machine-generated constructs produce
anything as unnecessary as Org's present solution. The situation now
becomes the following:
Pandoc: selective solution. In specific cases it returns {[}...{]}
Org: non-selective solution = ugly LaTeX code.
>> Anyway. As for the compilation, it is highly unlikely that \empty will
>> cause any unexpected error. But LaTeX and its over 6000 packages is
>> unpredictable. It also seemed unlikely that \relax would cause any
>> problems, and catching up on the last discussion, it had to be replaced
>> by \empty because it returned an error just before \hline. \relax is one
>> of the recommended solutions from LaTeX, because it tells LaTeX that the
>> previous macro has finished expanding, but it is recommended keeping in
>> mind that the user will apply it only when needed, not everywhere. And
>> before \hline it doesn't make sense because there will never be an
>> '\\[...]' error. So, in the current situation, we can ask ourselves: is
>> \empty everywhere safe? Everything points to yes. Can we be 100% sure?
>> ...?
>
> My answer is: "\\" is 100% not universally safe. Simply because we have
> that bug report with [ ... ] items in tables.
> So, anything with no concrete counter-example is better as long as we
> are reasonably sure that we are not breaking LaTeX conventions.
As I said, this is a known LaTeX problem that occurs in a rare case, for
which there is a known solution (or several), which should be applied in
the specific case. And Org already provides the necessary tools to apply
it.
>> The only thing I can think of, for a non-selective solution like the
>> current one, is the following: if \\ has an optional argument that must
>> be a length, then let's give it, but with a value of zero: \\[0pt], which
>> is equivalent to putting the value by default (zero) explicitly.
>
> This has been proposed and then rejected by Max in
> https://list.orgmode.org/orgmode/ti5tdb$rd2$1@ciao.gmane.io/ and he
> concluded that some side effects are present when using \\[0pt]:
>
> Max> \\[0pt]
> Max>
> Max> causes insertion of some code for negative vertical skip (of zero height
> Max> this case). It should not be really harmful, but I would avoid this
I would like to see some concrete example where this solution was
problematic. \\[0pt] is exactly the same as \\ (as for the effects).
Redundant but valid.
^ permalink raw reply [relevance 5%]
* Re: Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX)
2022-10-16 16:33 4% ` Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
2022-10-17 8:54 6% ` Ihor Radchenko
@ 2022-10-17 14:48 7% ` Max Nikulin
2022-10-19 11:08 5% ` Max Nikulin
2 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-10-17 14:48 UTC (permalink / raw)
To: emacs-orgmode
On 16/10/2022 23:33, Juan Manuel Macías wrote:
> Max Nikulin writes:
>>
>> I am surprised that \vspace is added instead of empty line between
>> stanzas.
>
> First of all, I'm afraid that in my previous post I mixed up two
> different issues: the verse block bug and my personal opinions about the
> new added constant. I should have separated these topics, sorry.
It was me who raised issues with verse exporter in discussion of newline
commands. I was impressed by hard to read elisp code and its result.
> I answer here what you comment about the verse blocks and later I will
> open a different thread for the other issue.
I am trying to read with enough attention this discussion, for a while I
have a couple of remarks specific to poetry.
> with the stanzaskip \length. I remember that I commented on this anomaly
> here on the list, a long time ago, but I can't find the original
> message...
https://list.orgmode.org/87k0tjasty.fsf@posteo.net/
Juan Manuel Macías. [Small suggestion] on exporting verse blocks to
LaTeX and vertical spaces. Tue, 15 Dec 2020 18:21:13 +0100
https://list.orgmode.org/?q=verse+vspace
> In my init I have redefined the verse block like this, so that there is
> a white line between stanzas, not \vspace
Do you still have real problems with current main HEAD state after
adjusting patterns in your code?
> (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
> vwidth
I have not verified it, but since I am not aware of a group wrapping
this fragment, I suspect that :versewidth may have global effect, not
limited to the current environment. Org variant of the function is
rather close at this point.
^ permalink raw reply [relevance 7%]
* Re: Line breaks and brackets in LaTeX export
2022-10-17 11:30 7% ` Line breaks and brackets in LaTeX export Juan Manuel Macías
2022-10-17 11:47 5% ` Ihor Radchenko
@ 2022-10-17 15:01 11% ` Juan Manuel Macías
2022-10-17 16:46 4% ` Max Nikulin
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-17 15:01 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Daniel Fleischer, Max Nikulin, emacs-orgmode
Juan Manuel Macías writes:
> So, in the current situation, we can ask ourselves: is
> \empty everywhere safe? Everything points to yes. Can we be 100% sure?
> ...?
I think I've found a case where \empty 'everywhere' can produce unexpected
results. I don't know if I'm missing something, because I've never used
this package, but taking a couple of random examples from the tabularray
documentation, you can see it, compiling the following snippet (by the
way, putting \\[0pt] instead of \\\empty the result is correct). Here in
both cases the problem is in the last \empty:
\documentclass{article}
\usepackage{tabularray}
\begin{document}
\section{Normal}
\begin{tblr}{lccr}
\hline
Alpha & Beta & Gamma & Delta \\
\hline
Epsilon & Zeta & Eta & Theta \\
\hline
Iota & Kappa & Lambda & Mu\\
\hline
\end{tblr}
\section{With `empty'}
\begin{tblr}{lccr}
\hline
Alpha & Beta & Gamma & Delta \\\empty
\hline
Epsilon & Zeta & Eta & Theta \\\empty
\hline
Iota & Kappa & Lambda & Mu\\\empty
\hline
\end{tblr}
\section{Normal}
\begin{tblr}[m]{hlines}
Alpha & Beta & Gamma \\
Epsilon & Zeta & Eta\\
Iota & Kappa & Lambda\\
\end{tblr}
\section{With `empty'}
\begin{tblr}[m]{hlines}
Alpha & Beta & Gamma \\\empty
Epsilon & Zeta & Eta\\\empty
Iota & Kappa & Lambda \\\empty
\end{tblr}
^ permalink raw reply [relevance 11%]
* Re: Line breaks and brackets in LaTeX export
2022-10-17 15:01 11% ` Juan Manuel Macías
@ 2022-10-17 16:46 4% ` Max Nikulin
2022-10-17 18:04 7% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Max Nikulin @ 2022-10-17 16:46 UTC (permalink / raw)
To: emacs-orgmode
On 17/10/2022 22:01, Juan Manuel Macías wrote:
>
> \documentclass{article}
> \usepackage{tabularray}
LaTeX I have installed is too old for this package. It is marked as
"Experimental LaTeX3", so I am unsure, maybe you have found a bug in
this package.
https://ctan.org/pkg/tabularray
You believe that an issue with brackets is extremely rare. It may be
true for humanitarian texts. For some users it may be a constant source
of pain e.g. in the case of interval notation as [a,b]. I have already
mentioned tables generated by code blocks, not typed directly. I can not
say that I often need to export my notes, but I was afraid that I will
be bitten by this bug because I may try to put dates close to left margin:
- Something\\
[2022-10-17 Mon]
By default dates wrapped into \textit, but it may be customized to just
"%s".
Selectively adding some workaround require complete reimplementation of
exporters. I have some curiosity concerning pandoc approach, but I am
unsure if I will reserve some time to read its code.
An idea how to avoid complete redesign: at first add something like
%__ORG_PROTECT_NEWLINE__
after each \\, later at an optimizing pass remove the comment if next
line does not start from a star or a square bracket, otherwise use some
workaround, e.g. "{[}". \relax may be suitable as well (in the beginning
of rows, not after \\).
I do not like approach with a custom command. It is effectively the same
as adding \empty but \\ may be redefined by some packages, so I strongly
prefer to keep \\ in exported markup. Redefining of \\ is a way to new
issues. I do not feel firm ground with a command that will expand to \\.
I am afraid that \\ may still consume following "[" unless \empty or its
equivalent is added after it. I am completely unsure concerning
tabularray parser that does not rely on TeX primitives.
I found \empty when I was looking for an approach with minimal overhead.
I expect that e.g. \\[0pt] may have higher performance penalty since it
is expanded to several commands. When the idea with "\\\relax" failed I
was choosing between "\\{}" and "\\\empty". I decided that the latter
minimizes risk to add spurious space.
Some problems:
I do not see a way to add some LaTeX code between table lines.
Semi-verbatim environment may be a source of new bugs. They may be
rather selective in respect to what they consider a command and what is
passed as raw text. tabularray perhaps is similar in this sense.
^ permalink raw reply [relevance 4%]
* Re: Best android app
2022-10-15 23:01 6% ` Juan Manuel Macías
2022-10-16 0:57 6% ` Ypo
@ 2022-10-17 18:01 5% ` Max Nikulin
2022-10-17 18:33 6% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2022-10-17 18:01 UTC (permalink / raw)
To: emacs-orgmode
On 16/10/2022 06:01, Juan Manuel Macías wrote:
> ypuntot writes:
>
>> https://easyorgmode.com/
>
> Proprietary license. This should not be recommended here
> (https://easyorgmode.com/terms).
I did not expected that this topic would become so hot.
Let's ignore that easyorg does not run on Android and concentrate on
proprietary vs. free app.
I believe that in such cases a helpful answer gently pushing users to
free software should be like: "Application P is a proprietary one. There
are F and G apps that have close set of features and superior for tasks
like T and D." Though such reply is almost impossible if discussion of P
is aggressively discouraged and sharing discussion summary on a web site
is prohibited because a web page may be associated with a GNU project.
Without mention of P the phrase becomes significantly less convincing,
it may give impression that people suggesting F and G are completely
unaware of what P really is.
I do not think that intention was to promote the particular app using a
GNU mail list, so my perception is that reaction without offering a free
alternative was harsh. It would be acceptable in the case more delay to
see that nobody can post a better answer.
I am unsure what is more strange, purism close in its degree to
absurdity or partial measures like wiping mentions of proprietary
software without removing of complete section
info "(org) Org Mobile" https://orgmode.org/manual/Org-Mobile.html
so that only a half of solution is really described. I would expect more
healthy balance.
P.S. Juan Manuel, from my point of view, your message suggesting running
emacs in termux is one of 2 helpful suggestions in this thread. Perhaps
the topic starter is seeking for a UI suitable for touch screen rather
than complete set of features, but due to lack of details we do not know it.
I have not tried any Org related application on Android, so I can not
suggest anything. I had a hope to learn something new from this topic.
^ permalink raw reply [relevance 5%]
* Re: Line breaks and brackets in LaTeX export
2022-10-17 16:46 4% ` Max Nikulin
@ 2022-10-17 18:04 7% ` Juan Manuel Macías
2022-10-18 4:41 6% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-17 18:04 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko, Vikas Rawal
Max Nikulin writes:
> On 17/10/2022 22:01, Juan Manuel Macías wrote:
>> \documentclass{article}
>> \usepackage{tabularray}
>
> LaTeX I have installed is too old for this package. It is marked as
> "Experimental LaTeX3", so I am unsure, maybe you have found a bug in
> this package.
> https://ctan.org/pkg/tabularray
As I said, I don't use this package. Once I wanted to start using it,
because it has many interesting features, but I gave up on it because
this package does not (at the moment) have support for the CMYK color
space (necessary for print publication) with the xcolors package.
Maybe it's a bug, but the situation is that compiling the copied
examples as they are in the package manual, the result is correct (as it
is also shown in the manual); but adding an unexpected element (an
\empty on the last line) produces a bad result. Since you can't test the
package, I've taken this screenshot:
https://i.imgur.com/jkSHUMP.png
I think there is a tabularray user on the list, Vikas Rawal. In fact, I
also remember that I provided a patch so that he could use this package
in Org
(https://list.orgmode.org/CALtzAB1yM+uG_xHghCxTLRX5mgbzNvT5+PO=DuaBB28nCsVqEA@mail.gmail.com/).
I've cc'd him in case he wants to join the discussion.
> You believe that an issue with brackets is extremely rare. It may be
> true for humanitarian texts. For some users it may be a constant
> source of pain e.g. in the case of interval notation as [a,b]. I have
> already mentioned tables generated by code blocks, not typed directly.
> I can not say that I often need to export my notes, but I was afraid
> that I will be bitten by this bug because I may try to put dates close
> to left margin:
>
> - Something\\
> [2022-10-17 Mon]
>
> By default dates wrapped into \textit, but it may be customized to
> just "%s".
>
> Selectively adding some workaround require complete reimplementation
> of exporters. I have some curiosity concerning pandoc approach, but I
> am unsure if I will reserve some time to read its code.
I see. If the selective solution is going to involve rewriting the
exporters, I find that it is unaffordable in the present circumstances.
It's a shame, because pandoc's solution seems ideal to me. What I
couldn't say is how pandoc does it and if it does it whenever expected,
because I use very little pandoc.
> I found \empty when I was looking for an approach with minimal
> overhead. I expect that e.g. \\[0pt] may have higher performance
> penalty since it is expanded to several commands. When the idea with
> "\\\relax" failed I was choosing between "\\{}" and "\\\empty". I
> decided that the latter minimizes risk to add spurious space.
Assuming that there is currently no alternative to the non-selective
solution, and that, as you say, the presence of brackets may be more
common than I initially expected, if I had to choose between \empty and
[0pt], I would say that [0pt] is the safest, as it is an expected
argument to \\ and equals the default space. I can't think of any
unexpected results from this, but of course, it also depends on there
being no package redefining \\ with another argument structure on its
own. I think it would be a bad idea for a package developer, but LaTeX
(and the LaTeX packages) is horribly unpredictable.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Best android app
2022-10-17 18:01 5% ` Max Nikulin
@ 2022-10-17 18:33 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-17 18:33 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> On 16/10/2022 06:01, Juan Manuel Macías wrote:
>> ypuntot writes:
>>
>>> https://easyorgmode.com/
>> Proprietary license. This should not be recommended here
>> (https://easyorgmode.com/terms).
>
> I did not expected that this topic would become so hot.
I didn't expect that either. And, since this response of mine has,
directly or indirectly, sparked a lengthy subsequent discussion, I think
I must apologize if my tone here may have sounded rude or impolite,
which was not my intention. It was a late hour, I was tired and English
is not my first language. So I opted for a minimal expression to remind
a user that the application he mentioned (in good faith) was proprietary
software. Probably, as I wrote it, the text gives the impression that I
was reprimanding this user. As I say, it was not my intention and
therefore I apologize for not having expressed it correctly.
^ permalink raw reply [relevance 6%]
* Re: Line breaks and brackets in LaTeX export
2022-10-17 18:04 7% ` Juan Manuel Macías
@ 2022-10-18 4:41 6% ` Ihor Radchenko
2022-10-18 14:23 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-10-18 4:41 UTC (permalink / raw)
To: Juan Manuel Macías, Daniel Fleischer
Cc: Max Nikulin, emacs-orgmode, Ihor Radchenko, Vikas Rawal
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Assuming that there is currently no alternative to the non-selective
> solution, and that, as you say, the presence of brackets may be more
> common than I initially expected, if I had to choose between \empty and
> [0pt], I would say that [0pt] is the safest, as it is an expected
> argument to \\ and equals the default space. I can't think of any
> unexpected results from this, but of course, it also depends on there
> being no package redefining \\ with another argument structure on its
> own. I think it would be a bad idea for a package developer, but LaTeX
> (and the LaTeX packages) is horribly unpredictable.
It is easy to change \\\empty constant to \\[0pt] if necessary. I have
no objection either way. Though I do not feel like we are in rush. I'd
like to hear from ox-latex maintainer.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Verse block and separations
2022-10-17 8:54 6% ` Ihor Radchenko
@ 2022-10-18 9:39 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-18 9:39 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
>> In my init I have redefined the verse block like this, so that there is
>> a white line between stanzas, not \vspace (I have also added some things
>> for the verse package, so that the numbering of verses is not broken).
>> So your example would produce a white line under \begin{verse}, not the
>> current \vspace, which would be irrelevant to LaTeX. But this is only a
>> hack:
>
> Could you provide a patch?
Sorry, I missed this message...
Sure, I think by the end of this week I'll be able to prepare a patch. I
put it on the agenda.
^ permalink raw reply [relevance 6%]
* Re: Line breaks and brackets in LaTeX export
2022-10-18 4:41 6% ` Ihor Radchenko
@ 2022-10-18 14:23 6% ` Juan Manuel Macías
2022-10-19 3:57 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-18 14:23 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Daniel Fleischer, Max Nikulin, emacs-orgmode, Ihor Radchenko,
Vikas Rawal
Ihor Radchenko writes:
>> Assuming that there is currently no alternative to the non-selective
>> solution, and that, as you say, the presence of brackets may be more
>> common than I initially expected, if I had to choose between \empty and
>> [0pt], I would say that [0pt] is the safest, as it is an expected
>> argument to \\ and equals the default space. I can't think of any
>> unexpected results from this, but of course, it also depends on there
>> being no package redefining \\ with another argument structure on its
>> own. I think it would be a bad idea for a package developer, but LaTeX
>> (and the LaTeX packages) is horribly unpredictable.
>
> It is easy to change \\\empty constant to \\[0pt] if necessary. I have
> no objection either way. Though I do not feel like we are in rush. I'd
> like to hear from ox-latex maintainer.
Today I have tried with the latest version of tabularray (2022C, the one
I tried yesterday was 2022A, included in TeX Live 2022), and the bad
results persist. Also, it now returns a compile error when an \empty
precedes a \hline. I suspect this package does a pretty drastic
redefinition of \\. The [0pt] option still works fine here, though.
^ permalink raw reply [relevance 6%]
* Re: Line breaks and brackets in LaTeX export
2022-10-18 14:23 6% ` Juan Manuel Macías
@ 2022-10-19 3:57 5% ` Ihor Radchenko
2022-10-19 5:11 0% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-10-19 3:57 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Daniel Fleischer, Max Nikulin, emacs-orgmode, Ihor Radchenko,
Vikas Rawal
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> It is easy to change \\\empty constant to \\[0pt] if necessary. I have
>> no objection either way. Though I do not feel like we are in rush. I'd
>> like to hear from ox-latex maintainer.
>
> Today I have tried with the latest version of tabularray (2022C, the one
> I tried yesterday was 2022A, included in TeX Live 2022), and the bad
> results persist. Also, it now returns a compile error when an \empty
> precedes a \hline. I suspect this package does a pretty drastic
> redefinition of \\. The [0pt] option still works fine here, though.
Then [0pt] should it be. At least for now, before we have a cleaner
solution.
See the attached patch.
[-- Attachment #2: 0001-org-latex-line-break-safe-Use-safer-value-of-0pt.patch --]
[-- Type: text/x-patch, Size: 4217 bytes --]
From b060f63078d65758f8fd2ab7725fbcf8b2de0057 Mon Sep 17 00:00:00 2001
Message-Id: <b060f63078d65758f8fd2ab7725fbcf8b2de0057.1666151751.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Wed, 19 Oct 2022 11:48:26 +0800
Subject: [PATCH] org-latex-line-break-safe: Use safer value of "\\[0pt]"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* lisp/ox-latex.el (org-latex-line-break-safe):
(org-latex-table-row):
Change \empty ending to explicit optional argument. \empty still has
undesired side effects in some cases.
* testing/lisp/test-org-table.el (test-org-table/to-latex):
* testing/lisp/test-ox-latex.el (test-ox-latex/verse): Update tests.
Reported-by: Juan Manuel Macías <maciaschain@posteo.net>
Link: https://orgmode.org/list/87o7u9rz1a.fsf@posteo.net
---
lisp/ox-latex.el | 12 ++++++------
testing/lisp/test-org-table.el | 6 +++---
testing/lisp/test-ox-latex.el | 12 ++++++------
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index dc8477d14..a5652fd78 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -278,17 +278,17 @@ (defconst org-latex-language-alist
- `:lang-name' the actual name of the language.")
-(defconst org-latex-line-break-safe "\\\\\\empty"
+(defconst org-latex-line-break-safe "\\\\[0pt]"
"Linebreak protecting the following [...].
-Without \"\\empty\" it would be interpreted as an optional argument to
+Without \"[0pt]\" it would be interpreted as an optional argument to
the \\\\.
This constant, for example, makes the below code not err:
\\begin{tabular}{c|c}
- [t] & s\\\\\\empty
- [I] & A\\\\\\empty
+ [t] & s\\\\[0pt]
+ [I] & A\\\\[0pt]
[m] & kg
\\end{tabular}")
@@ -4005,9 +4005,9 @@ (defun org-latex-table-row (table-row contents info)
(org-export-get-parent-table table-row) info))))
(format "%s
\\endfirsthead
-\\multicolumn{%d}{l}{%s} \\\\\\empty
+\\multicolumn{%d}{l}{%s} \\\\[0pt]
%s
-%s \\\\\\empty\n
+%s \\\\[0pt]\n
%s
\\endhead
%s\\multicolumn{%d}{r}{%s} \\\\
diff --git a/testing/lisp/test-org-table.el b/testing/lisp/test-org-table.el
index 722c37ea4..573179878 100644
--- a/testing/lisp/test-org-table.el
+++ b/testing/lisp/test-org-table.el
@@ -1635,11 +1635,11 @@ (ert-deftest test-org-table/to-generic ()
(ert-deftest test-org-table/to-latex ()
"Test `orgtbl-to-latex' specifications."
(should
- (equal "\\begin{tabular}{l}\na\\\\\\empty\n\\end{tabular}"
+ (equal "\\begin{tabular}{l}\na\\\\[0pt]\n\\end{tabular}"
(orgtbl-to-latex (org-table-to-lisp "| a |") nil)))
;; Test :environment parameter.
(should
- (equal "\\begin{tabularx}{l}\na\\\\\\empty\n\\end{tabularx}"
+ (equal "\\begin{tabularx}{l}\na\\\\[0pt]\n\\end{tabularx}"
(orgtbl-to-latex (org-table-to-lisp "| a |")
'(:environment "tabularx"))))
;; Test :booktabs parameter.
@@ -1648,7 +1648,7 @@ (ert-deftest test-org-table/to-latex ()
"\\toprule" (orgtbl-to-latex (org-table-to-lisp "| a |") '(:booktabs t))))
;; Handle LaTeX snippets.
(should
- (equal "\\begin{tabular}{l}\n\\(x\\)\\\\\\empty\n\\end{tabular}"
+ (equal "\\begin{tabular}{l}\n\\(x\\)\\\\[0pt]\n\\end{tabular}"
(orgtbl-to-latex (org-table-to-lisp "| $x$ |") nil)))
;; Test pseudo objects and :raw parameter.
(should
diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el
index 4fb9f2888..adb3a60ea 100644
--- a/testing/lisp/test-ox-latex.el
+++ b/testing/lisp/test-ox-latex.el
@@ -60,14 +60,14 @@ (ert-deftest test-ox-latex/verse ()
(should
(search-forward
"\\begin{verse}
-lorem ipsum dolor\\\\\\empty
-lorem ipsum dolor\\\\\\empty
+lorem ipsum dolor\\\\[0pt]
+lorem ipsum dolor\\\\[0pt]
\\vspace*{1em}
-lorem ipsum dolor\\\\\\empty
-lorem ipsum dolor\\\\\\empty
+lorem ipsum dolor\\\\[0pt]
+lorem ipsum dolor\\\\[0pt]
\\vspace*{1em}
-lorem ipsum dolor\\\\\\empty
-lorem ipsum dolor\\\\\\empty
+lorem ipsum dolor\\\\[0pt]
+lorem ipsum dolor\\\\[0pt]
\\end{verse}"))))
(provide 'test-ox-latex)
--
2.35.1
[-- Attachment #3: Type: text/plain, Size: 225 bytes --]
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply related [relevance 5%]
* Re: Line breaks and brackets in LaTeX export
2022-10-19 3:57 5% ` Ihor Radchenko
@ 2022-10-19 5:11 0% ` Max Nikulin
2022-10-19 11:16 5% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-10-19 5:11 UTC (permalink / raw)
To: emacs-orgmode
On 19/10/2022 10:57, Ihor Radchenko wrote:
> Juan Manuel Macías writes:
>>
>> Today I have tried with the latest version of tabularray (2022C, the one
>> I tried yesterday was 2022A, included in TeX Live 2022), and the bad
>> results persist. Also, it now returns a compile error when an \empty
>> precedes a \hline. I suspect this package does a pretty drastic
>> redefinition of \\. The [0pt] option still works fine here, though.
>
> Then [0pt] should it be. At least for now, before we have a cleaner
> solution.
It seems when I had a look into latex.ltx first time, I confused which
branch is executed when length is less than or equal to zero and decided
that it is the heavier \@xargarraycr. Actually \@yargarraycr do not
really worry me, so degree of my objection concerning \\[0pt]
significantly decreased.
\def\@argarraycr[#1]{%
\ifnum0=`{\fi}${}\ifdim #1>\z@ \@xargarraycr{#1}\else
\@yargarraycr{#1}\fi}
\def\@xargarraycr#1{\@tempdima #1\advance\@tempdima \dp \@arstrutbox
\vrule \@height\z@ \@depth\@tempdima \@width\z@ \cr}
\def\@yargarraycr#1{\cr\noalign{\vskip #1}}
I have realized that
| / | < | > |
| | a | b |
| | @@latex:\noalign{\vskip 1em}@@ c | d |
is not a workaround to increase local interval between rows. It may
cause disrupted vertical rules. Another recipe should be used:
| / | < | > |
| | a | b @@latex:\rule[-1em]{0pt}{1em}@@ |
| | c | d |
I believe that a more convenient way to override [0pt] to some other
length for particular row should exist, but I have no idea which syntax
should be used.
As to tabulararray, I still consider it as an experimental package.
Perhaps I will install a more modern container. I am curious what code
handles \\[0pt]. Likely I should read docs to get impression related to
design goals and approaches to implement them. The bug tracker of the
project looks like an appropriate place to ask a question concerning \\
variant safe for dumb exporters.
For a while I have the following question. Is \\{} have the same effect
on tabularray parser as \\\empty?
^ permalink raw reply [relevance 0%]
* Re: Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX)
2022-10-16 16:33 4% ` Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
2022-10-17 8:54 6% ` Ihor Radchenko
2022-10-17 14:48 7% ` Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Max Nikulin
@ 2022-10-19 11:08 5% ` Max Nikulin
2022-10-19 11:24 6% ` Verse block and separations Juan Manuel Macías
2 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-10-19 11:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
On 16/10/2022 23:33, Juan Manuel Macías wrote:
> (replace-regexp-in-string
> "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
> (replace-regexp-in-string
> "\\(\\\\\\\\\n\\)+\\([ \t]*\\\\\\\\\\)+" "\n"
> (replace-regexp-in-string
> "\\([ \t]*\\\\\\\\\\)?[ \t]*\n" "\\\\\n"
> (setq contents
> (if lin
> (replace-regexp-in-string "\\(\n\\)+\\([ \t]*\n\\)+" "\\\\\\\\!\n\n"
> contents)
> contents)) nil t) nil t) nil t) linreset)
I had a hope, it is possible to do it in a single pass of
`replace-regexp-in-string', but unfortunately the function does not
allow to make conditional substitution based on (rx (optional (group
string-start))) (a bug?).
I still prefer to avoid replacement of latex newlines back to empty
string. Though I am really happy with the following code, I expected a
more concise snippet. Unit tests may found bugs in it.
(let ((contents "\n\n 0 \n\n\na b\nc d e \n\n\nf g \n h i\n\n"))
;; Strip leading newlines.
(setq contents
(replace-regexp-in-string
(rx string-start (1+ (0+ blank) ?\n)) ""
contents 'fixed-case 'literal))
;; Add explicit line breaks and strip trailing spaces.
(setq contents
(replace-regexp-in-string
(rx (0+ blank) ?\n
(optional (group (1+ (0+ blank) ?\n)))
(optional (group (0+ blank) (not (any blank ?\n)))))
(lambda (m)
(let ((par (match-string 1 m))
(next (match-string 2 m)))
(if next
(concat (if par "\n\n" "\\\\\n")
next)
"")))
contents 'fixed-case 'literal))
;; Indented lines.
(replace-regexp-in-string
(rx line-start (1+ blank))
(lambda (m) (format "\\hspace*{%dem}" (length m)))
contents 'fixed-case 'literal))
Feel free to use it for inspiration during your work on a patch.
^ permalink raw reply [relevance 5%]
* Re: Line breaks and brackets in LaTeX export
2022-10-19 5:11 0% ` Max Nikulin
@ 2022-10-19 11:16 5% ` Juan Manuel Macías
2022-10-19 12:30 12% ` Juan Manuel Macías
[not found] ` <ac290c60-3b54-5521-eb16-82e6611dc6e2@gmail.com>
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-19 11:16 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Max Nikulin writes:
> Another recipe should be used:
>
> | / | < | > |
> | | a | b @@latex:\rule[-1em]{0pt}{1em}@@ |
> | | c | d |
>
> I believe that a more convenient way to override [0pt] to some other
> length for particular row should exist, but I have no idea which
> syntax should be used.
I think this new recipe you propose works fine, although I haven't
done a thorough test yet. In principle, it shouldn't be a problem.
By the way, now I remember that the package verse adds a series of extra
arguments to \\ (p. 6 in the documentation:
https://www.ctan.org/pkg/verse). As a user, the only way I can think of
to add arguments instead of [0pt] or \empty is by using a small export
filter to act on the final output. Perhaps putting something like
!!new-argument!! on the affected row/verse/line to guide the filter.
> As to tabulararray, I still consider it as an experimental package.
> Perhaps I will install a more modern container. I am curious what code
> handles \\[0pt]. Likely I should read docs to get impression related
> to design goals and approaches to implement them. The bug tracker of
> the project looks like an appropriate place to ask a question
> concerning \\ variant safe for dumb exporters.
Keep in mind that tabularray is a latex3 package and, in principle,
everything that is latex3 is here to stay. Certainly, it is a blessing
compared to the classic tabular environments, because it is tremendously
versatile. That is why it already has a significant number of users:
https://tex.stackexchange.com/questions/tagged/tabularray
And Org already provides what is necessary to use its syntax. I've had a
first look at tabularray.sty, but I'm not familiar enough with the new
LaTeX 3 syntax and, frankly, I'm lost...
I've tried all the packages involved in tables that I can think of
(longtable, siunitx, tabularx, booktabs, array, and I don't know if I
forgot any) and in all of them the \empty solution works fine. It seems
that tabularray is the black sheep here.
> For a while I have the following question. Is \\{} have the same
> effect on tabularray parser as \\\empty?
Throw an error before \hline.
^ permalink raw reply [relevance 5%]
* Re: Verse block and separations
2022-10-19 11:08 5% ` Max Nikulin
@ 2022-10-19 11:24 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-19 11:24 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> I still prefer to avoid replacement of latex newlines back to empty
> string. Though I am really happy with the following code, I expected a
> more concise snippet. Unit tests may found bugs in it.
>
> (let ((contents "\n\n 0 \n\n\na b\nc d e \n\n\nf g \n h i\n\n"))
> ;; Strip leading newlines.
> (setq contents
> (replace-regexp-in-string
> (rx string-start (1+ (0+ blank) ?\n)) ""
> contents 'fixed-case 'literal))
> ;; Add explicit line breaks and strip trailing spaces.
> (setq contents
> (replace-regexp-in-string
> (rx (0+ blank) ?\n
> (optional (group (1+ (0+ blank) ?\n)))
> (optional (group (0+ blank) (not (any blank ?\n)))))
> (lambda (m)
> (let ((par (match-string 1 m))
> (next (match-string 2 m)))
> (if next
> (concat (if par "\n\n" "\\\\\n")
> next)
> "")))
> contents 'fixed-case 'literal))
> ;; Indented lines.
> (replace-regexp-in-string
> (rx line-start (1+ blank))
> (lambda (m) (format "\\hspace*{%dem}" (length m)))
> contents 'fixed-case 'literal))
>
> Feel free to use it for inspiration during your work on a patch.
OK, thanks a lot. (BTW, I have yet to reply to some interesting things
you mention in this thread about the verse environment).
^ permalink raw reply [relevance 6%]
* Re: Line breaks and brackets in LaTeX export
2022-10-19 11:16 5% ` Juan Manuel Macías
@ 2022-10-19 12:30 12% ` Juan Manuel Macías
[not found] ` <ac290c60-3b54-5521-eb16-82e6611dc6e2@gmail.com>
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-19 12:30 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Juan Manuel Macías writes:
>> For a while I have the following question. Is \\{} have the same
>> effect on tabularray parser as \\\empty?
>
> Throw an error before \hline.
To expand on my answer: \\{} and \\\empty, before \hline, throw the same
error:
------------------------------
ERROR: Misplaced \noalign.
--- TeX said ---
\hline ->\noalign
{\ifnum 0=`}\fi \hrule \@height \arrayrulewidth \futurelet...
l.17 \end
{tblr}
--- HELP ---
From the .log file...
I expect to see \noalign only after the \cr of
an alignment. Proceed, and I'll ignore this case.
------------------------------
^ permalink raw reply [relevance 12%]
* Re: Line breaks and brackets in LaTeX export
@ 2022-10-20 16:55 4% ` Juan Manuel Macías
2022-10-21 3:34 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-20 16:55 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Max Nikulin writes:
> I have started a discussion requesting for a \\-like command without
> optional arguments. Maybe somebody will suggest a better workaround
> instead.
> https://github.com/lvjr/tabularray/discussions/321
I've had a look at the thread. What do you think of that
\NewTableCommand\empty{} workaround mentioned at
https://github.com/lvjr/tabularray/discussions/321#discussioncomment-3920957?
Since the \empty option only has problems in tabularray, maybe we could
keep it, and put in the documentation some recommendations for
tabularray users. I imagine they would have to add a @@latex:\empty@@
before each row that follows a line. A bit laborious, I'm afraid.
Another possibility that occurs to me is that the string reserved for
\empty, [0pt], etc., is a defcustom, with a value of \empty by default.
So the user would choose what suits him best.
By the way (a little digression), I was curious to see if these age-old
LaTeX problems with line breaking exist in ConTeXt as well. Since I'm
completely unfamiliar with ConTeXt, the quickest thing to do has been to
see what code ox-context returns for the org tables. The answer is that
there are no such problems, and one can safely put a square bracket at
the beginning of a row. It is also true that the table syntax in ConTeXt
is radically different from that in LaTeX. And there is also no problem
if I put @@context:a\[b]@@. Some screenshots:
https://i.imgur.com/2k1TaU9.png
https://i.imgur.com/8i9qlEH.png
Many times I've been tempted to give ConTeXt a try, but I've always run
into two things: ConTeXt's perennially experimental status and a
horrible lack of documentation. In addition, backward compatibility is
not usually respected, since ConTeXt, although it is free software, does
not have community development as a priority, but rather the company
behind it, Pragma.
>> I've tried all the packages involved in tables that I can think of
>> (longtable, siunitx, tabularx, booktabs, array, and I don't know if I
>> forgot any) and in all of them the \empty solution works fine. It seems
>> that tabularray is the black sheep here.
>
> I think tabularray is unique with a regexp-based parser. I had a hope
> that new approach does not allow newline between \\ and its arguments,
> but unfortunately compatibility with older code is preserved in this
> aspect.
>
> From LaTeX companion I remember supertabular as an alternative for
> longtable, but I am unsure if it is alive yet.
True, I had forgotten about this package (I don't think I've ever used
it). It looks like it has a 2020 new version:
@manual{supertabular,
title = {The \texttt{supertabular} package},
subtitle = {A multi-page tables package},
author = {Johannes L. Braams},
date = {2020-02-02},
version = {4.1g},
license = {lppl1.3c},
url = {https://mirror.ctan.org/macros/latex/contrib/supertabular},
pkgurl = {https://ctan.org/pkg/supertabular},
}
(bibtex entry obtained from: https://www.ctan.org/pkg/ctan-bibdata)
^ permalink raw reply [relevance 4%]
* Re: Line breaks and brackets in LaTeX export
[not found] ` <ac290c60-3b54-5521-eb16-82e6611dc6e2@gmail.com>
@ 2022-10-20 17:07 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-20 17:07 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> A workaround for tabularray:
>
> \NewTableCommand\empty{}
>
> I am unsure if we should use it.
Ah, I had just commented on this in the email I just sent...
>> By the way, now I remember that the package verse adds a series of
>> extra
>> arguments to \\ (p. 6 in the documentation:
>
> \\! command between stanzas to get proper line count makes things a
> bit more complicated. I believed that some TeX trick may be used
> instead of requirement of the explicit command.
In my custom code that I commented on in another email, \\! is
automatically inserted if verse numbering is active. My intention is to
incorporate that into my patch (work-in-progress) over the spaces between
verses.
^ permalink raw reply [relevance 6%]
* Re: Line breaks and brackets in LaTeX export
2022-10-20 16:55 4% ` Juan Manuel Macías
@ 2022-10-21 3:34 5% ` Ihor Radchenko
2022-10-21 16:38 0% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-10-21 3:34 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode, Ihor Radchenko
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I've had a look at the thread. What do you think of that
> \NewTableCommand\empty{} workaround mentioned at
> https://github.com/lvjr/tabularray/discussions/321#discussioncomment-3920957?
>
> Since the \empty option only has problems in tabularray, maybe we could
> keep it, and put in the documentation some recommendations for
> tabularray users. I imagine they would have to add a @@latex:\empty@@
> before each row that follows a line. A bit laborious, I'm afraid.
I see the tabularray issue simply as an example that \empty is not as
reliable as we thought. There might be other LaTeX packages throwing
errors on \\\empty.
The proposed workaround may be enough for tabularray, but may not be for
other packages.
> Another possibility that occurs to me is that the string reserved for
> \empty, [0pt], etc., is a defcustom, with a value of \empty by default.
> So the user would choose what suits him best.
I do not think that users will clearly understand the purpose of such
defcustom. It is solving some very narrow edge case, and it is unclear
why we would need to advertise changing it in customize interface.
I'd prefer to keep it as defconst, but maybe mention in the docstring
that it can still be set to "\\empty" as another semi-safe value. At the
user's own risk.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Line breaks and brackets in LaTeX export
2022-10-21 3:34 5% ` Ihor Radchenko
@ 2022-10-21 16:38 0% ` Max Nikulin
2022-10-21 19:32 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-10-21 16:38 UTC (permalink / raw)
To: emacs-orgmode
On 21/10/2022 10:34, Ihor Radchenko wrote:
> Juan Manuel Macías writes:
>
> I see the tabularray issue simply as an example that \empty is not as
> reliable as we thought. There might be other LaTeX packages throwing
> errors on \\\empty.
My impression is that tabularray has an ambitious goal to replace all
current table packages. I have no idea if other packages will adopt
similar approach with regexp-based parsing instead of usual expanding of
TeX commands.
I do not like necessity to add \NewTableCommand\empty{} to documents
somehow (only if tabularray is loaded). I do not have an idea better
than \\[0pt] and an optimizing filter to remove [0pt] in almost all cases.
^ permalink raw reply [relevance 0%]
* Re: Line breaks and brackets in LaTeX export
2022-10-21 16:38 0% ` Max Nikulin
@ 2022-10-21 19:32 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-21 19:32 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Max Nikulin writes:
> My impression is that tabularray has an ambitious goal to replace all
> current table packages. I have no idea if other packages will adopt
> similar approach with regexp-based parsing instead of usual expanding
> of TeX commands.
Yes, that's the impression I have too. Tabularray certainly solves a lot
of traditional LaTeX table problems (unfortunately not the one we're
dealing with). Time will tell if it also creates other new problems. In
any case, it brings a lot of flexibility to a part of LaTeX, tables,
that has always suffered from a certain constriction. We'll see what
happens. LaTeX is becoming very complex and now several layers coexist,
since the jump to LaTeX 3 is going to be gradual. On the other hand, I
don't know if the latex core developers have a cleaner \\ command in
their roadmap, without those absurd current problems (and that LaTeX has
been carrying for almost 40 years).
> I do not like necessity to add \NewTableCommand\empty{} to documents
> somehow (only if tabularray is loaded). I do not have an idea better
> than \\[0pt] and an optimizing filter to remove [0pt] in almost all
> cases.
I totally agree.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Line breaks and brackets in LaTeX export
@ 2022-10-22 12:26 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-22 12:26 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Or, to be completely safe, we can introduce a defcustom that will
> control such clean-up (clean up by default).
>
> I propose the following:
> 1. Merge my patch with \\[0pt] safe page breaks
> 2. Modify org-latex-template to replace unnecessary occurrences of
> "\\[0pt]" in CONTENTS when org-latex-compact-latex (you may propose
> other defcustom names) is non-nil.
>
> WDYT?
+1
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [off-topic] E-readers and Org-Mode
@ 2022-10-23 15:16 9% Juan Manuel Macías
2022-10-24 7:09 6% ` Fraga, Eric
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-23 15:16 UTC (permalink / raw)
To: orgmode
Hi all,
As I am beginning to have serious eye fatigue problems, I am thinking of
buying an e-ink device, not to read books but to read documents. My idea
is that it be an Android device and that it supports the installation of
apk, to be able to install Termux/Emacs/Org-Mode and Nextcloud to sync
with my desktop PC or my laptop. I'd like to explore a workflow where I
could read PDFs on the device (and probably also text-only web pages
with eww) and also take Org Mode notes.
I wonder if anyone has tried something similar, if there is anything
written about it somewhere or if it is completely uncharted territory.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [off-topic] E-readers and Org-Mode
2022-10-23 15:16 9% [off-topic] E-readers and Org-Mode Juan Manuel Macías
@ 2022-10-24 7:09 6% ` Fraga, Eric
2022-10-24 11:50 4% ` Juan Manuel Macías
2022-10-25 14:37 5% ` Max Nikulin
2 siblings, 1 reply; 200+ results
From: Fraga, Eric @ 2022-10-24 7:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Dear Juan Manuel,
On Sunday, 23 Oct 2022 at 15:16, Juan Manuel Macías wrote:
> Hi all,
>
> As I am beginning to have serious eye fatigue problems, I am thinking of
> buying an e-ink device, not to read books but to read documents.
> My idea is that it be an Android device and that it supports the
> installation of apk, to be able to install Termux/Emacs/Org-Mode and
> Nextcloud to sync with my desktop PC or my laptop. I'd like to explore
> a workflow where I could read PDFs on the device (and probably also
> text-only web pages with eww) and also take Org Mode notes.
Putting aside the org mode aspect for the moment, I highly recommend the
reMarkable [1] tablet for reading PDF documents. I have owned one for
several years now and use it all the time (in particular for reading 300
pages theses on the train...). I do not use org mode on it, however.
For Emacs, some people have hacked the reMarkable. I have not tried any
of the hacks but the Parabola initiative [2] seems the most advanced.
HTH,
eric
Footnotes:
[1] https://remarkable.com/
[2] http://www.davisr.me/projects/parabola-rm/,
--
: Eric S Fraga, with org release_9.5.5-966-g88c85d in Emacs 29.0.50
^ permalink raw reply [relevance 6%]
* Re: [off-topic] E-readers and Org-Mode
2022-10-24 7:09 6% ` Fraga, Eric
@ 2022-10-24 11:50 4% ` Juan Manuel Macías
2022-10-24 15:30 6% ` Fraga, Eric
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-24 11:50 UTC (permalink / raw)
To: Org Mode List
Hi, Eric,
Fraga, Eric writes:
> Putting aside the org mode aspect for the moment, I highly recommend the
> reMarkable [1] tablet for reading PDF documents. I have owned one for
> several years now and use it all the time (in particular for reading 300
> pages theses on the train...). I do not use org mode on it, however.
>
> For Emacs, some people have hacked the reMarkable. I have not tried any
> of the hacks but the Parabola initiative [2] seems the most advanced.
>
> HTH,
> eric
>
> Footnotes:
> [1] https://remarkable.com/
>
> [2] http://www.davisr.me/projects/parabola-rm/,
Thanks a lot for the pointers. I didn't know about it, but something
like reMarkable is what I'm looking for, a device that serves as a
substitute for printed paper in A4 and reading on a desktop screen. The
Parabola hack looks pretty cool (that's supposed to be equivalent to
being able to use Emacs with pdf-tools package). I have seen that the
Wi-Fi does not work (it is not essential for me) but the OTG does. I
will investigate about it... In that device line I had also seen the
Onyx Boox Note. But recently I read that this brand has a sad history of
violating the Linux kernel GPL license.
N.B.: I have to say that I have never used an e-ink device. The
''closest'' thing is this hack I wrote, for use especially on my old
Thinkpad in high light environments. It uses Picom compositor and
Redshift. And, after messing around with the parameters a lot, I found
these that I'm quite satisfied with. It also helps to apply a monochrome
theme in Emacs. Of course, it is nothing more than a simulation to try
to reduce the light emission as much as possible:
#+begin_src emacs-lisp
(setq picom-command "picom --backend glx --glx-fshader-win \"uniform sampler2D tex; uniform float opacity; void main() { vec4 color = texture2D(tex, gl_TexCoord[0].xy); gl_FragColor = vec4(vec3(0.2126 * color.r + 0.7152 * color.g + 0.0722 * color.b) * opacity, color.a * opacity); }\"")
(setq redshift-command "redshift -l 40.5914000:-4.1474000 -b 0.9:0.9 -t 4000k:4000k -g 0.5:0.5:0.8")
(defun my-poor-man-eink-toggle ()
(interactive)
(when (equal (process-status "picom") 'run)
(kill-process "picom"))
(if (and (not (equal (process-status "picom-g") 'run))
(not (equal (process-status "redshifg-g") 'run)))
(progn
(shell-command "killall picom")
(shell-command "killall redshift-gtk")
(shell-command "redshift -x")
(start-process-shell-command "redshift-g" nil redshift-command)
(start-process-shell-command "picom-g" nil picom-command))
(kill-process "picom-g")
(kill-process "redshift-g")
(shell-command "redshift -x")
(start-process-shell-command "redshift" nil "redshift-gtk -c ~/.redshift.conf")))
#+end_src
^ permalink raw reply [relevance 4%]
* Re: [off-topic] E-readers and Org-Mode
@ 2022-10-24 14:11 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-24 14:11 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: Org Mode List
Pedro Andres Aranda Gutierrez writes:
> My workflow is to create an HTML from the org file(s) and then
> generate an EPUB2 file forthe reader (in my case Kobo or Cervantes
> Light) I have always felt the rendition is much more confortable than
> PDF. Other readers may be better suited for PDF.
Thanks, Pedro. BTW, have you tried org-epub
(http://github.com/ofosos/org-epub)? I don't usually work with epubs,
but the few times that I need to export to epub it usually works for me.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [off-topic] E-readers and Org-Mode
2022-10-24 11:50 4% ` Juan Manuel Macías
@ 2022-10-24 15:30 6% ` Fraga, Eric
0 siblings, 0 replies; 200+ results
From: Fraga, Eric @ 2022-10-24 15:30 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Org Mode List
On Monday, 24 Oct 2022 at 11:50, Juan Manuel Macías wrote:
> The Parabola hack looks pretty cool (that's supposed to be equivalent
> to being able to use Emacs with pdf-tools package).
Be aware (as I wasn't when I answered your previous post) that Parabola
is not free in the $ sense although the author claims it is free in the
libre sense.
--
: Eric S Fraga, with org release_9.5.5-966-g88c85d in Emacs 29.0.50
^ permalink raw reply [relevance 6%]
* Re: [off-topic] E-readers and Org-Mode
@ 2022-10-24 18:34 5% ` Juan Manuel Macías
2022-10-25 7:57 6% ` Fraga, Eric
2022-10-29 9:03 12% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-24 18:34 UTC (permalink / raw)
To: Fraga, Eric; +Cc: Jeffrey DeLeo, orgmode
Fraga, Eric writes:
> On Monday, 24 Oct 2022 at 17:42, Jeffrey DeLeo wrote:
>> I am very happy with my Kobo Elipsa
>
> Your workflow is very similar to that of mine on the reMarkable and the
> two units are similar in size etc. It's a workflow that is fine for
> annotating documents (which is what I want) but definitely no link to
> org mode for the OP... ;-)
Indeed. Both Kobo Elipsa and reMarkable are very tempting and in a
similar price range. The main problem I find is that they both also run
closed and, presumably, proprietary software. I don't know if my
knowledge (and my time) would be enough to try to hack them. And I
imagine that I would run the risk of ending up bricking the gadget.
The annotations by hand with the stylus are difficult to translate to
Org :-) but in any case they are tremendously useful and save
considerable paper and ink.
I wonder if these devices are capable of exporting normal annotations in
plain text or xml? Anyway, I think it would be possible to write some
python script[1] to extract the annotations and then parse the resulting
xml from there to get a nice and beautiful Org document. Which also
leads me to wonder if anyone has tried that. I think it's a good
entertainment for a vacation...
[1] https://stackoverflow.com/questions/1106098/parse-annotations-from-a-pdf
^ permalink raw reply [relevance 5%]
* Re: [off-topic] E-readers and Org-Mode
2022-10-24 18:34 5% ` Juan Manuel Macías
@ 2022-10-25 7:57 6% ` Fraga, Eric
2022-10-25 12:55 6% ` Juan Manuel Macías
2022-10-29 9:03 12% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Fraga, Eric @ 2022-10-25 7:57 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Jeffrey DeLeo, orgmode
On Monday, 24 Oct 2022 at 18:34, Juan Manuel Macías wrote:
> The main problem I find is that they both also run
> closed and, presumably, proprietary software.
They both run Linux but with proprietary user interfaces.
> I wonder if these devices are capable of exporting normal annotations in
> plain text or xml?
The annotations are not text: they are vector data corresponding to the
movement of the stylus. You can extract that information (I have
software for the reMarkable that does so) but doing character
recognition would be challenging...
--
: Eric S Fraga, with org release_9.5.5-1023-g48b237 in Emacs 29.0.50
^ permalink raw reply [relevance 6%]
* Re: [off-topic] E-readers and Org-Mode
2022-10-25 7:57 6% ` Fraga, Eric
@ 2022-10-25 12:55 6% ` Juan Manuel Macías
2022-10-25 13:59 6% ` Fraga, Eric
2022-10-26 13:31 6% ` L.C. Karssen
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-25 12:55 UTC (permalink / raw)
To: Org Mode List; +Cc: Fraga, Eric, Jeffrey DeLeo
Fraga, Eric writes:
>> I wonder if these devices are capable of exporting normal annotations in
>> plain text or xml?
>
> The annotations are not text: they are vector data corresponding to the
> movement of the stylus. You can extract that information (I have
> software for the reMarkable that does so) but doing character
> recognition would be challenging...
I see... I was referring to annotations entered as text. Can't you do
annotations on those devices like you do in a typical PDF reader,
Acrobat or Okular style, using an on-screen keyboard or a physical
keyboard? It's those kinds of annotations I was referring to, the ones
that are stored as metadata in the PDF.
As for the stylus notes, I think I would find them useful especially for
proof reading. But very often what I need is just to put text. In Org I
use Org-noter + pdf-tools a lot.
^ permalink raw reply [relevance 6%]
* Re: [off-topic] E-readers and Org-Mode
2022-10-25 12:55 6% ` Juan Manuel Macías
@ 2022-10-25 13:59 6% ` Fraga, Eric
2022-10-26 13:31 6% ` L.C. Karssen
1 sibling, 0 replies; 200+ results
From: Fraga, Eric @ 2022-10-25 13:59 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Org Mode List, Jeffrey DeLeo
On Tuesday, 25 Oct 2022 at 12:55, Juan Manuel Macías wrote:
> I see... I was referring to annotations entered as text. Can't you do
> annotations on those devices like you do in a typical PDF reader,
Not as far as I know (for the reMarkable; I have no experience with the
Elipsa). The virtual keyboard, on the reMarkable, is not great in any
case. Very rudimentary; enough for the job (naming files, connecting to
WiFi) but just barely.
> As for the stylus notes, I think I would find them useful especially for
> proof reading.
Indeed and, for my use cases, for reviewing journal articles and
for giving feedback to students on their reports or theses.
--
: Eric S Fraga, with org release_9.5.5-1028-gcd835d in Emacs 29.0.50
^ permalink raw reply [relevance 6%]
* Re: [off-topic] E-readers and Org-Mode
2022-10-23 15:16 9% [off-topic] E-readers and Org-Mode Juan Manuel Macías
2022-10-24 7:09 6% ` Fraga, Eric
@ 2022-10-25 14:37 5% ` Max Nikulin
2 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-10-25 14:37 UTC (permalink / raw)
To: emacs-orgmode
On 23/10/2022 22:16, Juan Manuel Macías wrote:
>
> As I am beginning to have serious eye fatigue problems, I am thinking of
> buying an e-ink device, not to read books but to read documents. My idea
> is that it be an Android device and that it supports the installation of
> apk, to be able to install Termux/Emacs/Org-Mode and Nextcloud to sync
> with my desktop PC or my laptop.
E-ink displays are slow (my device was manufactured 15 years ago but I
do not expect dramatic improvement), so applications should be heavily
optimized to provide acceptable experience. I do not think that Emacs is
suitable.
The wonderful property of reflective display is that its brightness
follows ambient conditions. (Almost) direct sunlight during image
refresh (page switching) may cause low contrast noisy image. A
workaround is to move the book into shadow or close cover for a moment.
For static image bright light is not a problem.
I am curious if pdf-tools is able to display annotations created on
devices with stilus.
^ permalink raw reply [relevance 5%]
* Re: [off-topic] E-readers and Org-Mode
2022-10-25 12:55 6% ` Juan Manuel Macías
2022-10-25 13:59 6% ` Fraga, Eric
@ 2022-10-26 13:31 6% ` L.C. Karssen
1 sibling, 0 replies; 200+ results
From: L.C. Karssen @ 2022-10-26 13:31 UTC (permalink / raw)
To: emacs-orgmode
On 25-10-2022 15:55, Juan Manuel Macías wrote:
> Fraga, Eric writes:
>
>>> I wonder if these devices are capable of exporting normal annotations in
>>> plain text or xml?
>>
>> The annotations are not text: they are vector data corresponding to the
>> movement of the stylus. You can extract that information (I have
>> software for the reMarkable that does so) but doing character
>> recognition would be challenging...
>
> I see... I was referring to annotations entered as text. Can't you do
> annotations on those devices like you do in a typical PDF reader,
> Acrobat or Okular style, using an on-screen keyboard or a physical
> keyboard? It's those kinds of annotations I was referring to, the ones
> that are stored as metadata in the PDF.
Another happy reMarkable user here. It looks like the upcoming v3.0 of
the software will allow entering text via the on-screen keyboard.
Whether that is only for 'regular' notes or also for PDF annotation is
not yet clear to me (source:
https://support.remarkable.com/s/article/Software-release-3-0-beta).
Best regards,
Lennart.
>
> As for the stylus notes, I think I would find them useful especially for
> proof reading. But very often what I need is just to put text. In Org I
> use Org-noter + pdf-tools a lot.
>
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
's-Hertogenbosch
The Netherlands
lennart@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
^ permalink raw reply [relevance 6%]
* Re: Error opening an .org file
@ 2022-10-27 17:21 10% ` Juan Manuel Macías
2022-10-28 9:25 5% ` Tim Cross
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-27 17:21 UTC (permalink / raw)
To: Renato Pontefice; +Cc: emacs-orgmode
Renato Pontefice writes:
> I’ve edited and commented all the lines of it. And The error
> persist. So (was you told)maybe the error is not of init.el
> But I’m unable to run emacs from termnal.
> How can I do?
> I’m in Mac osx 12.6.1 where do I can find emacs?
Renato, I'm not a Mac user, but I imagine it will be like any other
Unix: you have to launch a terminal from your desktop (i guess there
will be in macos an app called "terminal" or something like that), and
once inside the terminal, just type:
emacs --debug-init
and press enter. Emacs (GUI) will open and you should pay attention to
the error messages that Emacs will show you. That will give you a clue
as to where the error is in your Emacs startup.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [off-topic] E-readers and Org-Mode
@ 2022-10-27 17:53 8% ` Juan Manuel Macías
2022-10-28 4:40 6% ` Ihor Radchenko
2022-10-29 12:54 5% ` Max Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-27 17:53 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> I see that definitely it is possible, but I am unsure it is more
> convenient than OLED or LCD tablet. 4 regimes for screen is an
> indicator of some complications. Choice of Android may be a way to
> avoid development of custom UI. I have not checked if it is possible
> to build custom Android variant, unlock bootloader and still get
> comparable performance.
>
> Where was a period when LCD monitors were slow in comparison to CRT
> ones and people complained concerning annoying trails on dynamic
> images...
Precisely, a couple of days ago, in my search for information on this
subject, I found a e-ink device, likebook, that a) runs Android and b)
has an option to be able to see things on the screen like a normal
tablet, that is, that you can watch videos and more. Grayscale, of
course, but without the problems of a typical e-ink screen. In yt there
are some videos that show this double use. It's interesting. Anyway I
don't know if a custom build of Android can be installed on this device.
Actually, the idea of a device running Android is interesting because it
allows you to install termux and thus Emacs. You could even use Emacs
GUI by installing a GNU/Linux distro in termux and loading it as proot
(+ vnc), or just activating the X11 repo in termux, but I don't know
what the performance would be like. Probably horrible.
On the other hand, the only free app to annotate PDFs on Android is
pen&pdf (based on muPDF), but it hasn't been maintained for several
years. It can be installed on F-droid by adding the IzzyOnDroid
repository, but I don't know if installing it would be a security
risk...
Everything said in this threed is very interesting, but now I am
hesitating between buying one of these devices or simply a 10-inch
tablet with a good screen, and then applying all possible blue light
filters to it. By activating the developer options, you can also turn
Android grayscale. Of course it's not the same as an e-ink screen, but
maybe I can work it out.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [off-topic] E-readers and Org-Mode
2022-10-27 17:53 8% ` Juan Manuel Macías
@ 2022-10-28 4:40 6% ` Ihor Radchenko
2022-10-29 12:54 5% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-10-28 4:40 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Actually, the idea of a device running Android is interesting because it
> allows you to install termux and thus Emacs. You could even use Emacs
> GUI by installing a GNU/Linux distro in termux and loading it as proot
> (+ vnc), or just activating the X11 repo in termux, but I don't know
> what the performance would be like. Probably horrible.
I am using MobiScribe. It is running android. Though it is more tailored
for writing and drawing.
> Everything said in this threed is very interesting, but now I am
> hesitating between buying one of these devices or simply a 10-inch
> tablet with a good screen, and then applying all possible blue light
> filters to it. By activating the developer options, you can also turn
> Android grayscale. Of course it's not the same as an e-ink screen, but
> maybe I can work it out.
There is a world of difference between e-ink and normal screen. You
really need to try at least once before you decide.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Error opening an .org file
2022-10-27 17:21 10% ` Juan Manuel Macías
@ 2022-10-28 9:25 5% ` Tim Cross
0 siblings, 0 replies; 200+ results
From: Tim Cross @ 2022-10-28 9:25 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Renato Pontefice writes:
>
>> I’ve edited and commented all the lines of it. And The error
>> persist. So (was you told)maybe the error is not of init.el
>> But I’m unable to run emacs from termnal.
>> How can I do?
>> I’m in Mac osx 12.6.1 where do I can find emacs?
>
> Renato, I'm not a Mac user, but I imagine it will be like any other
> Unix: you have to launch a terminal from your desktop (i guess there
> will be in macos an app called "terminal" or something like that), and
> once inside the terminal, just type:
>
> emacs --debug-init
>
> and press enter. Emacs (GUI) will open and you should pay attention to
> the error messages that Emacs will show you. That will give you a clue
> as to where the error is in your Emacs startup.
>
It has been a while since I used macOS. However, how you start emacs in
a terminal depends on how emacs was installed and which version of
emacs.
Note that the emacs which macOS includes is VERY old (I think it is
Emacs 21). This is really too old to be useful these days. You need to
install a current version of Emacs. My recommendation would be to use
homebrew to do this. However, I fear, based on the questions ask, the
OPs familiarity of the OS is likely to make installing homebrew and then
emacs a bit challenging to do via email. Certainly would be off topic
for the org mode list. Possibly better help would be available via the
emacs help list. I would try to help further, but I don't have a working
macOS system at present, so cannot refresh/verify the steps to get
sufficient clarity to be helpful.
^ permalink raw reply [relevance 5%]
* Re: Org mode, Org Mode, Org-mode or Org-Mode?
@ 2022-10-28 20:55 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-28 20:55 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: Org-Mode mailing list
Marcin Borkowski writes:
> What is the "official" version? I found at least two spelling on
> orgmode.org...
Interesting question. When I don't write carelessly I try to write "Org
Mode", but it's more out of habit. The wikipedia entry says "Org-mode".
The Google entry for orgmode.org says "Org mode", however the title of
the website says "Org Mode".
I imagine this disparity is also shared by other famous Emacs modes,
where you see them written in various ways...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [off-topic] E-readers and Org-Mode
2022-10-24 18:34 5% ` Juan Manuel Macías
2022-10-25 7:57 6% ` Fraga, Eric
@ 2022-10-29 9:03 12% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-29 9:03 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> [...] Anyway, I think it would be possible to write some python
> script[1] to extract the annotations and then parse the resulting xml
> from there to get a nice and beautiful Org document. Which also leads
> me to wonder if anyone has tried that.
I've found that org-noter has the `org-noter-create-skeleton' function,
which exports PDF annotations to Org and keeps them in sync with the PDF
(via pdf-tools). Tremendously useful! :-)
^ permalink raw reply [relevance 12%]
* Re: [off-topic] E-readers and Org-Mode
2022-10-27 17:53 8% ` Juan Manuel Macías
2022-10-28 4:40 6% ` Ihor Radchenko
@ 2022-10-29 12:54 5% ` Max Nikulin
2022-10-31 12:18 8% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2022-10-29 12:54 UTC (permalink / raw)
To: emacs-orgmode
On 28/10/2022 00:53, Juan Manuel Macías wrote:
>
> Everything said in this threed is very interesting, but now I am
> hesitating between buying one of these devices or simply a 10-inch
> tablet with a good screen, and then applying all possible blue light
> filters to it.
Another option is a hardware filter: yellow glasses. I am unsure if the
following statement is trustworthy, but marketing is based on suppressed
chromatic aberration inside eyes.
I think, you should decide what is better for your sight: active screen
and perhaps dark theme or paper-like reflective display. Some people
complains that particular devices may have annoying flickering at low
screen brightness due to pulse width modulation. Some devices have too
bright screen even when brightness is set to min value.
If it is acceptable to you to limit device usage to reading and
handwritten notes then a e-Ink might be really great. You can extend
such notes in Emacs on a PC later.
P.S. Concerning free PDF annotation tool, I have not tested if it is
convenient and available on Android, but Firefox-106 release notes have
the following entry:
> It is now possible to edit PDFs: including writing text, drawing, and
adding signatures.
Almost certainly "edit" in their parlance in namely annotations, not
real changes of PDF structure.
^ permalink raw reply [relevance 5%]
* Re: Cannot find therefore at 972 character...
@ 2022-10-29 12:57 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-29 12:57 UTC (permalink / raw)
To: Renato Pontefice; +Cc: emacs-orgmode
Renato Pontefice writes:
> I tried ib more way, but I’m unable to see where the error is.
>
> Can you help me? Please
>
> Renato
>
> Otherwise I haver to put away all that I’ve done and restart from0
Renato, can you please put the content of your
/Users/renatopontefice/.emacs.d/init.el file here? (copy and paste). Of
course, if your file has sensitive information like passwords and such,
don't forget to remove that before posting it here).
As you've already been told, there's an error in your file, but we can't
help you if we don't see it.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Position 972
@ 2022-10-29 18:16 7% ` Juan Manuel Macías
2022-10-29 18:44 7% ` tomas
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-29 18:16 UTC (permalink / raw)
To: Renato Pontefice; +Cc: emacs-orgmode
Renato Pontefice writes:
> Bruno,
> With the common you told me I reach che 972 /M-g c 972) and I found this:
>
> ;;;;;;Org mode configuration
> Enable Org mode
> (require ‘org)
>
> Could be this the error?
>
> Now I’ve erased the two ;; save init.el and restart emacs, but now I obtain:
> -------------------------------------------------------------
> Warning (initialization): An error occurred while loading ‘/Users/renatopontefice/.emacs.d/init.el’:
>
> Symbol's value as variable is void: Enable
>
> To ensure normal operation, you should investigate and remove the
> cause of the error in your initialization file. Start Emacs with
> the ‘--debug-init’ option to view a complete error backtrace. Disable showing Disable logging
> ———————————————————————————————
>
> What’s now…
Renato, adding to what Tomas and Bruno have explained to you very well,
you have another case in the init that you sent me by mail. Notice the
third line here:
------------------
;; Make Org mode work with files ending in .org
(add-to-list 'auto-mode-alist '("\\.org$" . org-mode))
The above is the default in recent emacsen
(require 'org)
(setq org-log-done t)
------------------
Emacs will understand The line that begins "The above is the..." as
code, and it is not code but a comment to the code. Therefore, you must
protect that line with an escape character, which in Elisp is (at least)
one ";" (as Tomas explained to you):
;; Make Org mode work with files ending in .org
(add-to-list 'auto-mode-alist '("\\.org$" . org-mode))
;; The above is the default in recent emacsen
(require 'org)
(setq org-log-done t)
And you also have another case, towards the end:
---------------------
(custom-set-variables
;;custom-set-variables was added by Custom.
;;If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
;; '(package-selected-packages '(org-contacts frame-tabs ebdb)))
::(custom-set-faces
;; custom-set-faces was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
;;)
--------------------
The first line (custom-set-variables) is the beginning of a code that is
commented out (= protected, so that Emacs doesn't read it). This line
should also be commented out (protected), with ;. Otherwise Emacs will
run into a code that starts but doesn't have a resolution.
If you fix that and the line that starts with "Enable", you should no
longer have errors in your init.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Position 972
@ 2022-10-29 18:29 6% ` Juan Manuel Macías
2022-10-29 18:42 6% ` tomas
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-29 18:29 UTC (permalink / raw)
To: Renato Pontefice; +Cc: emacs-orgmode
Renato Pontefice writes:
> Symbol's value as variable is void: ‘org
It's 'org not ‘org. Notice the difference between the quotes[1]. (Did you
modify that part? It was correct before).
[1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Quoting.html
^ permalink raw reply [relevance 6%]
* Re: Position 972
2022-10-29 18:29 6% ` Juan Manuel Macías
@ 2022-10-29 18:42 6% ` tomas
0 siblings, 0 replies; 200+ results
From: tomas @ 2022-10-29 18:42 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 699 bytes --]
On Sat, Oct 29, 2022 at 06:29:33PM +0000, Juan Manuel Macías wrote:
> Renato Pontefice writes:
>
> > Symbol's value as variable is void: ‘org
>
> It's 'org not ‘org. Notice the difference between the quotes[1]. (Did you
> modify that part? It was correct before).
Perhaps it was Google (through gmail) who modified it. They do that kind
of things. We don't know.
@Renato: it seems your init.el is badly mangled. Please, go through it
and look for pieces of private information. If there are any, remove
them and post the rest for us to see (this has been suggested a couple
of times). That will be a lot quicker than to chase every single bug
in the dark.
Cheers
--
t
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Position 972
2022-10-29 18:16 7% ` Juan Manuel Macías
@ 2022-10-29 18:44 7% ` tomas
0 siblings, 0 replies; 200+ results
From: tomas @ 2022-10-29 18:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Renato Pontefice, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]
On Sat, Oct 29, 2022 at 06:16:30PM +0000, Juan Manuel Macías wrote:
[...]
> Renato, adding to what Tomas and Bruno have explained to you very well,
> you have another case in the init that you sent me by mail. Notice the
> third line here:
Oh, I get it that Juan Manuel has received one copy of the init.el.
Then I take back my last mail :-)
Cheers
--
t
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [relevance 7%]
* Re: org-fstree.el overview over directories (but no comments are possible)
@ 2022-10-30 12:52 9% ` Juan Manuel Macías
2022-10-30 13:10 1% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-30 12:52 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> The only problem is one cannot add comments in the sense when the tree
> is updated everything gets replaced
> as indicated:
>
> ;; - when triggering an update (by pressing "C-c C-c" while in the line mentioned above)
> ;; the COMPLETE REGION BETWEEN "#+BEGIN_FSTREE" AND "#+END_FSTREE" IS REPLACED.
> ;; - speed
>
>
> So I am wondering. Is there any new package or an update I am not aware
> of that would allow adding comments?
Hi Uwe,
I tried this package a long time ago, and I found the problems you
mention. I noticed also that in large directories it took a eternity to
create the Org nodes. The idea of the package is not bad, but I did not
find a practical use for it. I currently have dired-subtree-toggle
installed, which allows expanding and collapsing dired directories, and
assigned these keyboard shortcuts to it:
(with-eval-after-load 'dired
(define-key dired-mode-map (kbd "<tab>") 'dired-subtree-toggle)
(define-key dired-mode-map (kbd "C-<tab>") 'dired-subtree-cycle))
As to whether there is any new package that does the same thing as
org-fstree, AFAIK I don't think so. Out of curiosity, what use case
would you give to such a package?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-fstree.el overview over directories (but no comments are possible)
2022-10-30 12:52 9% ` Juan Manuel Macías
@ 2022-10-30 13:10 1% ` Uwe Brauer
2022-10-30 13:56 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-10-30 13:10 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2473 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
Hi Juan,
> Uwe Brauer writes:
>> The only problem is one cannot add comments in the sense when the tree
>> is updated everything gets replaced
>> as indicated:
>>
>> ;; - when triggering an update (by pressing "C-c C-c" while in the line mentioned above)
>> ;; the COMPLETE REGION BETWEEN "#+BEGIN_FSTREE" AND "#+END_FSTREE" IS REPLACED.
>> ;; - speed
>>
>>
>> So I am wondering. Is there any new package or an update I am not aware
>> of that would allow adding comments?
> Hi Uwe,
> I tried this package a long time ago, and I found the problems you
> mention. I noticed also that in large directories it took a eternity to
> create the Org nodes. The idea of the package is not bad, but I did not
> find a practical use for it. I currently have dired-subtree-toggle
> installed, which allows expanding and collapsing dired directories, and
> assigned these keyboard shortcuts to it:
> (with-eval-after-load 'dired
> (define-key dired-mode-map (kbd "<tab>") 'dired-subtree-toggle)
> (define-key dired-mode-map (kbd "C-<tab>") 'dired-subtree-cycle))
> As to whether there is any new package that does the same thing as
> org-fstree, AFAIK I don't think so.
Well I found one
https://github.com/ScriptDevil/org-fs-tree
But again I cannot add comments, nor seems there be a update function.
> Out of curiosity, what use case would you give to such a package?
Well, since I tend to forget things, and it is very time consuming to
open files and see what is the basic content, I thought of adding to
each directory (with subdirectories if necessary) I find useful a
README.org file, that contains a
1. Tree of the directory and
1. a short description of the content of each file
I use bookmarks.el but that is an entirely different workflow, since I
there only save files that I find useful, but sometimes I stumble across
a directory I created some time ago and don't recall the content of
each file.
> Best regards,
> Juan Manuel
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 1%]
* Re: org-fstree.el overview over directories (but no comments are possible)
2022-10-30 13:10 1% ` Uwe Brauer
@ 2022-10-30 13:56 9% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-30 13:56 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Well, since I tend to forget things, and it is very time consuming to
> open files and see what is the basic content, I thought of adding to
> each directory (with subdirectories if necessary) I find useful a
> README.org file, that contains a
>
> 1. Tree of the directory and
>
> 1. a short description of the content of each file
>
> I use bookmarks.el but that is an entirely different workflow, since I
> there only save files that I find useful, but sometimes I stumble across
> a directory I created some time ago and don't recall the content of
> each file.
I see. It's not exactly what you're looking for, but I often use
filetags.el (https://github.com/DerBeutlin/filetags.el) which allows you
to add tags to files and directories in Dired. You can add multiple
tags, remove or update them. It's not a panacea, because the tags are
added directly to the file/directory name (as part of the name, I mean),
but in general it's enough for me when I want to have a file tagged in
some way. I can then locate this files by tag names using helm-locate.
Perhaps a kind of ''dired-org-view'' could be interesting, to display a
dired directory as an Org buffer, where you could add (persistent) TODO
states, notes and tags. Well, it's a sudden occurrence, I don't know to
what extent it is feasible, but in case someone feels inspired... :-)
You also have this package (haven't tried it):
https://github.com/Boruch-Baum/emacs-diredc Adds a lot of functionality
to Dired, including file preview.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-fstree.el overview over directories (but no comments are possible)
@ 2022-10-30 15:40 9% ` Juan Manuel Macías
2022-10-30 16:42 0% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-30 15:40 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Thanks I will give it a try, meanwhile I am trying filetree (in Melpa)
> that allows you to add notes to files, but it seems you have to open the
> files in order to add the notes, which is not what I am looking for
Interesting package, I didn't know about it... Have you ever tried it? I
just installed it, but M-x filetree-load-cmd-menu returns a 'Wrong type
argument: number-or-marker-p, list'. When I run toggle-debug-on-error It
seems it's a transient related problem...
hmm, I think the notes functionality that this package includes is more
in the league of org-remark or org-noter, i.e. to add notes to the file
content, but not a comment to the file itself, which I think is more
what you search. But I am not sure.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-fstree.el overview over directories (but no comments are possible)
2022-10-30 15:40 9% ` Juan Manuel Macías
@ 2022-10-30 16:42 0% ` Uwe Brauer
0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2022-10-30 16:42 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer writes:
>> Thanks I will give it a try, meanwhile I am trying filetree (in Melpa)
>> that allows you to add notes to files, but it seems you have to open the
>> files in order to add the notes, which is not what I am looking for
> Interesting package, I didn't know about it... Have you ever tried it? I
> just installed it, but M-x filetree-load-cmd-menu returns a 'Wrong type
> argument: number-or-marker-p, list'. When I run toggle-debug-on-error It
> seems it's a transient related problem...
Hm it works for me (emacs master git may),
> hmm, I think the notes functionality that this package includes is more
> in the league of org-remark or org-noter, i.e. to add notes to the file
> content, but not a comment to the file itself, which I think is more
> what you search. But I am not sure.
I think you are right, I will open an issue on the authors github page.
BTW I played a bit with filetags. It is ok, but I would like to add some
more information, usually a line or so a tag is a bit sparse I must say.
Hm
> Best regards,
> Juan Manuel
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: org-fstree.el overview over directories (but no comments are possible)
@ 2022-10-30 18:17 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-30 18:17 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Hm I played around with filetags and it is quite nice, I think, thanks
> for pointing it out to me.
>
> I would be extremely interested how you use helm-locate in that context,
> and you give me an example, please?
>
> For example I have the following tags added to a specific directory
> bio-hoja4 -- EDO Uwe.tex
> and
> h1A_ECM_n -- analysis1.tex
>
> How would I use helm-locate to search those tags?
At first I used a controlled vocabulary for the tags, setting the
variables filetags-enforce-controlled-vocabulary and
filetags-controlled-vocabulary. But I was getting some false positives.
So it occurred to me to configure this other variable like this:
(setq filetags-delimiter-between-filename-and-tags "%ftag_")
This way, if I start typing in helm-locate %ftag_ I already start
getting more accurate results. Like I said, it's not a panacea, but it
more or less does the trick :-)
BTW, i don't use helm-locate directly but helm-mini with a number of
sources related to buffers, markers, and files:
(setq helm-mini-default-sources '(helm-source-buffers-list
helm-source-recentf
helm-source-buffer-not-found
helm-source-bookmarks
helm-source-bookmark-set
helm-source-locate))
So with a single call to helm-mini I can get information about open
buffers, recent files, bookmarks, and locate.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-fstree.el overview over directories (but no comments are possible)
@ 2022-10-30 19:04 9% ` Juan Manuel Macías
2022-10-30 19:21 0% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-30 19:04 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> I have a file called bio-hoja4%ftag_EDO Uwe.pdf
>
> I use helm-locate and type %ftag_
> but I receive nothing found see the screenshot.
>
>
> helm-min
>
> And typing %ftag also does not work,
>
> What do I miss?
Ah, sorry, I thought you used helm-locate before. helm-locate depends on
the GNU/Linux 'locate' program. You have to install it. I don't know
what distro you use, but the package is usually called mlocate or
plocate (these are two different implementations of locate). I have
mlocate installed on Arch Linux. According to the Arch wiki:
------------
- mlocate (Merging Locate) is a more secure version of the locate utility,
that only shows files accessible to the user.
- plocate (Posting Locate) is a locate based on posting lists, consuming
mlocates database ahead-of-time and making a much faster (and smaller)
index out of it.
------------
Generally, when you install locate it is automatically configured so
that the database is updated every time you start a session. If you want
to update it in the middle of a session, you must execute the updatedb
command with sudo in the terminal.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-fstree.el overview over directories (but no comments are possible)
2022-10-30 19:04 9% ` Juan Manuel Macías
@ 2022-10-30 19:21 0% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-10-30 19:21 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 1567 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer writes:
>> I have a file called bio-hoja4%ftag_EDO Uwe.pdf
>>
>> I use helm-locate and type %ftag_
>> but I receive nothing found see the screenshot.
>>
>>
>> helm-min
>>
>> And typing %ftag also does not work,
>>
>> What do I miss?
> Ah, sorry, I thought you used helm-locate before. helm-locate depends on
> the GNU/Linux 'locate' program. You have to install it. I don't know
> what distro you use, but the package is usually called mlocate or
> plocate (these are two different implementations of locate). I have
> mlocate installed on Arch Linux. According to the Arch wiki:
> ------------
> - mlocate (Merging Locate) is a more secure version of the locate utility,
> that only shows files accessible to the user.
> - plocate (Posting Locate) is a locate based on posting lists, consuming
> mlocates database ahead-of-time and making a much faster (and smaller)
> index out of it.
> ------------
> Generally, when you install locate it is automatically configured so
> that the database is updated every time you start a session. If you want
> to update it in the middle of a session, you must execute the updatedb
> command with sudo in the terminal.
Ah, well I have installed locate (mlocate to be precise, I am using
Ubuntu)
And I have used locate in the past, nevertheless
helm-locate keeps failing and giving me the screenshot I attached in my
earlier message, so some sort of bug in helm-locate for Ubuntu?
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [correction]
@ 2022-10-30 19:51 10% ` Juan Manuel Macías
2022-10-30 21:23 0% ` [correction] Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-30 19:51 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> But not not -- which is the
> (setq filetags-delimiter-between-filename-and-tags " -- ")
>
> orginal setting, hm, not sure why this is so
I think locate can't look for things like " -- "; Also, it's too
generic. It is safer to use alphanumeric characters. For example, if you
prefer something shorter, you can do:
(setq filetags-delimiter-between-filename-and-tags " @@ ")
That should be found by locate.
Regarding the updatedb issue, it seems that in Ubuntu you have to do it
manually. You would have to edit the crontab file. See:
https://askubuntu.com/questions/203597/how-do-i-run-updatedb-everyday
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [correction]
2022-10-30 19:51 10% ` [correction] Juan Manuel Macías
@ 2022-10-30 21:23 0% ` Uwe Brauer
2022-10-31 12:22 10% ` [correction] Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-10-30 21:23 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 630 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer writes:
>> But not not -- which is the
>> (setq filetags-delimiter-between-filename-and-tags " -- ")
>>
>> orginal setting, hm, not sure why this is so
> I think locate can't look for things like " -- "; Also, it's too
> generic. It is safer to use alphanumeric characters. For example, if you
> prefer something shorter, you can do:
> (setq filetags-delimiter-between-filename-and-tags " @@ ")
I see, thanks. Last most likely trivial question, where, in which file
does filetags save the relevant information, i.e tags
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [off-topic] E-readers and Org-Mode
2022-10-29 12:54 5% ` Max Nikulin
@ 2022-10-31 12:18 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-31 12:18 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> P.S. Concerning free PDF annotation tool, I have not tested if it is
> convenient and available on Android, but Firefox-106 release notes
> have the following entry:
>
>> It is now possible to edit PDFs: including writing text, drawing,
> and adding signatures.
>
> Almost certainly "edit" in their parlance in namely annotations, not
> real changes of PDF structure.
Interesting, I'll take a look at it. I haven't used firefox as my
default browser in a while. On desktop and laptop I use a combination of
Eww and Qutebrowser, which is more keyboard oriented. I have Firefox
almost relegated to negotiations with the Spanish government, such as
taxes and little else. On mobile I use Brave browser. And lately I've
noticed that it's not as hard as I thought to navigate with Eww-mode in
Termux/Emacs by touch! :-)
BTW, I have found another free app to annotate PDF on Android, KOReader:
https://f-droid.org/en/packages/org.koreader.launcher.fdroid/ It is
mainly intended for e-ink screen e-readers. It's under active
development as well (https://github.com/koreader), and even offers
builds and tutorials for installing it on specific non-Android devices
(Kobo, reMarkable, etc.).
I have tried to make some annotations on a PDF to open it later on the
desktop pc. Annotations are correctly read by pdf-tools, Atril, Evince,
Okular, etc. And they are also exported correctly to Org via the
org-noter function org-noter-create-skeleton, which I didn't know about
and is tremendously useful.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [correction]
2022-10-30 21:23 0% ` [correction] Uwe Brauer
@ 2022-10-31 12:22 10% ` Juan Manuel Macías
2022-10-31 12:55 0% ` [correction] Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-31 12:22 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> I see, thanks. Last most likely trivial question, where, in which file
> does filetags save the relevant information, i.e tags
I haven't looked at the code, but I imagine that the information is
stored in the variables I mentioned before, when you use a controlled
vocabulary for the tags. You can also store them in a .filetags file.
See: https://github.com/DerBeutlin/filetags.el#usage
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [correction]
2022-10-31 12:22 10% ` [correction] Juan Manuel Macías
@ 2022-10-31 12:55 0% ` Uwe Brauer
2022-10-31 15:08 10% ` [correction] Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-10-31 12:55 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer writes:
>> I see, thanks. Last most likely trivial question, where, in which file
>> does filetags save the relevant information, i.e tags
> I haven't looked at the code, but I imagine that the information is
> stored in the variables I mentioned before, when you use a controlled
> vocabulary for the tags. You can also store them in a .filetags file.
> See: https://github.com/DerBeutlin/filetags.el#usage
Thanks, just some comments.
I played bit with the format of the separators.
1. I don't want space in my file names, so I set
(setq filetags-delimiter-between-tags "_")
2. I want filetags-delimiter-between-filename-and-tags to be
- Clearly visiable
- Easily to find
- not in conflict with other programs.
- So I tried (setq filetags-delimiter-between-filename-and-tags
"_**_") not good for searching
- "_::_" is not very visiable
- "_##_" is in conflict with the latexviewers when you have
forward and backward search on in pdf files.
- "_&&_" seems to be ok but I am not entirely sure about it
Any comments?
Regards
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [correction]
2022-10-31 12:55 0% ` [correction] Uwe Brauer
@ 2022-10-31 15:08 10% ` Juan Manuel Macías
2022-10-31 15:48 0% ` [correction] Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-31 15:08 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> - "_&&_" seems to be ok but I am not entirely sure about it
"&&" will give you trouble if you manipulate the file in a shell,
because it will be understood as the '&&' operator. You would have to
use escape characters.
Maybe "@@" or "%%" are safer choices. Look at this screenshot:
https://i.imgur.com/eGXepU3.png
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [correction]
2022-10-31 15:08 10% ` [correction] Juan Manuel Macías
@ 2022-10-31 15:48 0% ` Uwe Brauer
2022-10-31 16:23 10% ` [correction] Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-10-31 15:48 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 923 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer writes:
>> - "_&&_" seems to be ok but I am not entirely sure about it
> "&&" will give you trouble if you manipulate the file in a shell,
> because it will be understood as the '&&' operator. You would have to
> use escape characters.
> Maybe "@@" or "%%" are safer choices. Look at this screenshot:
%% does not work for auctex, so I think I try @@, I hope it does not collide with anything fancy......
> https://i.imgur.com/eGXepU3.png
> Best regards,
> Juan Manuel
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [correction]
2022-10-31 15:48 0% ` [correction] Uwe Brauer
@ 2022-10-31 16:23 10% ` Juan Manuel Macías
2022-10-31 16:33 0% ` [correction] Uwe Brauer
2022-10-31 16:58 0% ` [correction] Uwe Brauer
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-31 16:23 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> %% does not work for auctex, so I think I try @@, I hope it does not collide with anything fancy......
You can also set a text string, like _ftags_, and to hide it when you're
in Dired, add a function to the dired-mode-hook that displays an overlay
instead of that string, with some fancy unicode symbol separated by
spaces. Something like this:
(defun overlay-dired-filetags ()
(save-excursion
(goto-char (point-min))
(while
(re-search-forward "\\(_ftag_\\)" nil t)
(let
((ov (make-overlay (match-beginning 1) (match-end 1)))
(tag (propertize " ⚜ " 'face 'bold)))
(overlay-put ov 'overlay-tag t)
(overlay-put ov 'display tag)))))
However, in large directories I don't know how that would affect
performance.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [correction]
2022-10-31 16:23 10% ` [correction] Juan Manuel Macías
@ 2022-10-31 16:33 0% ` Uwe Brauer
2022-10-31 16:58 0% ` [correction] Uwe Brauer
1 sibling, 0 replies; 200+ results
From: Uwe Brauer @ 2022-10-31 16:33 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 852 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer writes:
>> %% does not work for auctex, so I think I try @@, I hope it does not collide with anything fancy......
> You can also set a text string, like _ftags_, and to hide it when you're
> in Dired, add a function to the dired-mode-hook that displays an overlay
> instead of that string, with some fancy unicode symbol separated by
> spaces. Something like this:
> (defun overlay-dired-filetags ()
> (save-excursion
> (goto-char (point-min))
> (while
> (re-search-forward "\\(_ftag_\\)" nil t)
> (let
> ((ov (make-overlay (match-beginning 1) (match-end 1)))
> (tag (propertize " ⚜ " 'face 'bold)))
> (overlay-put ov 'overlay-tag t)
> (overlay-put ov 'display tag)))))
Very nice thanks, I might try that out later....
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [correction]
2022-10-31 16:23 10% ` [correction] Juan Manuel Macías
2022-10-31 16:33 0% ` [correction] Uwe Brauer
@ 2022-10-31 16:58 0% ` Uwe Brauer
2022-10-31 17:35 10% ` [correction] Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Uwe Brauer @ 2022-10-31 16:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer writes:
>> %% does not work for auctex, so I think I try @@, I hope it does not collide with anything fancy......
> You can also set a text string, like _ftags_, and to hide it when you're
> in Dired, add a function to the dired-mode-hook that displays an overlay
> instead of that string, with some fancy unicode symbol separated by
> spaces. Something like this:
> (defun overlay-dired-filetags ()
> (save-excursion
> (goto-char (point-min))
> (while
> (re-search-forward "\\(_ftag_\\)" nil t)
> (let
> ((ov (make-overlay (match-beginning 1) (match-end 1)))
> (tag (propertize " ⚜ " 'face 'bold)))
> (overlay-put ov 'overlay-tag t)
> (overlay-put ov 'display tag)))))
> However, in large directories I don't know how that would affect
> performance.
Hm I tried out
(defun overlay-dired-filetags ()
(save-excursion
(goto-char (point-min))
(while
(re-search-forward "\\(_ftag_\\)" nil t)
(let
((ov (make-overlay (match-beginning 1) (match-end 1)))
(tag (propertize " ⚜ " 'face 'bold)))
(overlay-put ov 'overlay-tag t)
(overlay-put ov 'display tag)))))
(add-hook 'dired-mode-hook 'overlay-dired-filetags)
But
my-auctex-init_ftag_emacs.el
Still gets displayed as
my-auctex-init_ftag_emacs.el
What do I miss?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [correction]
2022-10-31 16:58 0% ` [correction] Uwe Brauer
@ 2022-10-31 17:35 10% ` Juan Manuel Macías
2022-10-31 17:38 0% ` [correction] Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-31 17:35 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Still gets displayed as
> my-auctex-init_ftag_emacs.el
>
> What do I miss?
You're right, sorry. I'm afraid I was too hasty and the code from the
other message, as I put it, will never work :-).
You can test how it looks, however, if you evaluate the function in a
dired buffer, but the moment you revert the buffer the overlay is lost,
as expected.
That has to be solved in another way. Perhaps some code from the
all-the-icons-dired package can be reused.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [correction]
2022-10-31 17:35 10% ` [correction] Juan Manuel Macías
@ 2022-10-31 17:38 0% ` Uwe Brauer
2022-10-31 21:01 6% ` [correction] Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-10-31 17:38 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer writes:
>> Still gets displayed as
>> my-auctex-init_ftag_emacs.el
>>
>> What do I miss?
> You're right, sorry. I'm afraid I was too hasty and the code from the
> other message, as I put it, will never work :-).
> You can test how it looks, however, if you evaluate the function in a
> dired buffer, but the moment you revert the buffer the overlay is lost,
> as expected.
Right, that I can confirm
> That has to be solved in another way. Perhaps some code from the
> all-the-icons-dired package can be reused.
Don't worry, for the moment _@@ is fine for me
> Best regards,
> Juan Manuel
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [correction]
2022-10-31 17:38 0% ` [correction] Uwe Brauer
@ 2022-10-31 21:01 6% ` Juan Manuel Macías
2022-11-01 7:13 0% ` [correction] Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-31 21:01 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Don't worry, for the moment _@@ is fine for me
I think with font-lock-add-keywords it should work. I have put another
overlay on the tags, so that they are seen inside a box, separated by
":".
(defun overlay-dired-filetags (&optional lim)
(when
(re-search-forward "\\(_ftag_\\)\\(.+\\)" lim t)
(let
((ov (make-overlay (match-beginning 1) (match-end 1)))
(tag (propertize " ⚜ " 'face 'bold))
(ov-2 (make-overlay (match-beginning 2) (match-end 2)))
(tags (propertize (replace-regexp-in-string
"_"
":"
(match-string 2))
'font-lock-face
'(:foreground "red" :box t))))
(overlay-put ov 'overlay-tag t)
(overlay-put ov 'display tag)
(overlay-put ov-2 'overlay-tag-2 t)
(overlay-put ov-2 'display tags))))
(font-lock-add-keywords
'dired-mode
'((overlay-dired-filetags (0 'font-lock-keyword-face t)))
t)
^ permalink raw reply [relevance 6%]
* Re: [correction]
2022-10-31 21:01 6% ` [correction] Juan Manuel Macías
@ 2022-11-01 7:13 0% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-11-01 7:13 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer writes:
>> Don't worry, for the moment _@@ is fine for me
> I think with font-lock-add-keywords it should work. I have put another
> overlay on the tags, so that they are seen inside a box, separated by
> ":".
> (defun overlay-dired-filetags (&optional lim)
> (when
> (re-search-forward "\\(_ftag_\\)\\(.+\\)" lim t)
> (let
> ((ov (make-overlay (match-beginning 1) (match-end 1)))
> (tag (propertize " ⚜ " 'face 'bold))
> (ov-2 (make-overlay (match-beginning 2) (match-end 2)))
> (tags (propertize (replace-regexp-in-string
> "_"
> ":"
> (match-string 2))
> 'font-lock-face
> '(:foreground "red" :box t))))
> (overlay-put ov 'overlay-tag t)
> (overlay-put ov 'display tag)
> (overlay-put ov-2 'overlay-tag-2 t)
> (overlay-put ov-2 'display tags))))
*Excellent* works very nicely. Thanks very much, the only change I did
was
(tag (propertize " 🎃 " 'face 'bold))
It is better visible, and more fitting since you sent me the final
version on Halloween 👹
Now it remains to configure helm-locate, so that it takes a local
database that I can run regularly without sudo..
Thanks very much that was very helpful
Uwe
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Docstrings and literate programming (good practices?)
@ 2022-11-01 14:07 7% Juan Manuel Macías
2022-11-02 7:13 6% ` Ihor Radchenko
2022-11-03 20:54 5% ` Rudolf Adamkovič
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-01 14:07 UTC (permalink / raw)
To: orgmode
Hi all,
I find docstrings very useful. One can learn a great deal about Elisp
just from describe-function and describe-variable. But I don't find the
best way for docstrings to fit into the "precepts" of literate
programming. I try to explain myself: today I am reviewing my Emacs
init, written in Org. I like to document the code neatly, so that my
future self knows what my present self was trying to do. But I realize
that many of those global explanations before a function or a variable
can also be in a docstring. I can duplicate the text, but it seems to be
a bit redundant, right? So what is the best way to proceed when doing
literate programming with any language that supports docstrings?
Apologies in advance if the question is a bit silly, but I'm not a
professional programmer and don't have an academic background in it,
so I don't know if there is any good practice on these things :-)
On the other hand, the following procedure has occurred to me: put the
relevant information in an Org src block. When exporting to a human
readable format (PDF, HTML, etc.), the content is exported as part of
the text. When tangling, the block content is exported as a docstring.
First, I defined this function:
(defun my-org-format-docstring (cont)
(with-temp-buffer
(insert cont)
(save-excursion
(goto-char (point-min))
(while (re-search-forward org-emph-re nil t)
(replace-match (concat " " (match-string 4) " ") t nil)))
(setq cont
(string-trim
(replace-regexp-in-string
"\\(\"\\)"
"\\\\\\1"
(org-export-string-as (buffer-string) 'ascii t)))))
(format "\"%s\"" cont))
And an example of use:
#+NAME: format-docstring
#+begin_src emacs-lisp :exports none :var x="" :tangle no
(if (not org-export-current-backend)
(my-org-format-docstring x)
x)
#+end_src
#+NAME: docstring1
#+begin_src org :post format-docstring(*this*) :results replace :exports results :tangle no
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.
#+end_src
#+begin_src emacs-lisp :noweb strip-export :exports code
(defun foo ()
<<docstring1()>>
(message "hello world"))
#+end_src
The only drawback is that with :noweb strip-export an empty line is
left.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Line breaks and brackets in LaTeX export
@ 2022-11-01 16:55 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-01 16:55 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: Ihor Radchenko, orgmode
Max Nikulin writes:
> LaTeX verse package require "\\!" as stanza separator to get proper line count,
> so square bracket on the next line is not the only character that may change
> meaning of "\\". So "[*!>" (depending on context) should be handled.
Only when the separation between stanzas is made by means of a blank
line. With the current behavior of verse blocks in the export to LaTeX,
where the separation between stanzas is done by a \vspace, there is no
problem.
When, months ago, I contributed the LaTeX verse numbering patch, I took
this into account, and it didn't seem like the right time to change the
default behavior of the verse block.
I hope to be able to send a new patch soon in the few days (according to
what we discussed in past messages) where the separation by stanzas is
applied by means of a blank line (which is the right thing to do in
LaTeX). I'm rewriting my old code for verse numbering so that a \\! is
automatically added in the last line of each stanza when line numbering
is on.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [correction]
@ 2022-11-01 13:52 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-01 13:52 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> One, hopefully, last thing in helm-mini, how can I select and visit a
> certain file? I looked around but C-j says view file (recent) but I
> cannot edit that file....
The selected candidates in helm have one main action, which in
helm-locate and so on is usually to visit the buffer or file. The action
is associated with enter or C-m. But you can modify the helm-map to your
liking.
And, in addition to the main action, you have a menu of (very useful)
secondary actions, which you can access by pressing tab on the selected
candidate. Each helm source has its own secondary actions. And you can
also define more actions and add them.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Docstrings and literate programming (good practices?)
2022-11-01 14:07 7% Docstrings and literate programming (good practices?) Juan Manuel Macías
@ 2022-11-02 7:13 6% ` Ihor Radchenko
2022-11-02 7:53 0% ` Dr. Arne Babenhauserheide
2022-11-02 12:49 8% ` Juan Manuel Macías
2022-11-03 20:54 5% ` Rudolf Adamkovič
1 sibling, 2 replies; 200+ results
From: Ihor Radchenko @ 2022-11-02 7:13 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> #+NAME: docstring1
> #+begin_src org :post format-docstring(*this*) :results replace :exports results :tangle no
> 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.
> #+end_src
You can also have
#+name: docstring1
: 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.
> #+begin_src emacs-lisp :noweb strip-export :exports code
> (defun foo ()
> <<docstring1()>>
> (message "hello world"))
> #+end_src
>
> The only drawback is that with :noweb strip-export an empty line is
> left.
Why do you need to strip docstring on export?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Docstrings and literate programming (good practices?)
2022-11-02 7:13 6% ` Ihor Radchenko
@ 2022-11-02 7:53 0% ` Dr. Arne Babenhauserheide
2022-11-02 12:49 8% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Dr. Arne Babenhauserheide @ 2022-11-02 7:53 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Juan Manuel Macías, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]
Ihor Radchenko <yantar92@posteo.net> writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> #+NAME: docstring1
>> #+begin_src org :post format-docstring(*this*) :results replace :exports results :tangle no
>> 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.
>> #+end_src
>
> You can also have
>
> #+name: docstring1
> : 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.
>
>> #+begin_src emacs-lisp :noweb strip-export :exports code
>> (defun foo ()
>> <<docstring1()>>
>> (message "hello world"))
>> #+end_src
Both of these options look awesome! Thank you for sharing!
The first (org-block) for long-form text (like official javadoc), the
second (just verbatim) for shorter docstrings.
They finally solve a long-standing problem for me.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Docstrings and literate programming (good practices?)
2022-11-02 7:13 6% ` Ihor Radchenko
2022-11-02 7:53 0% ` Dr. Arne Babenhauserheide
@ 2022-11-02 12:49 8% ` Juan Manuel Macías
2022-11-02 13:05 5% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-02 12:49 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Why do you need to strip docstring on export?
Hi Ihor,
Thanks for the suggestion. The problem with doing it this way is that
the paragraph is exported as verbatim, and I want it to be exported as a
normal part of the text. For example, in a PDF or HTML it would say
something like:
---
This awesome function is for blah blah, and makes blah blah, when blah blah.
[the function code]
---
But in the source file, that text would be a docstring, inside the
function code.
Actually I don't know if it's good practice to do it like this, hence my
doubts about how to 'marry' the literate programming concept with
languages that support docstring, which, somehow, are largely
self-documenting (thanks to the existence of the docstring itself) . The
scenario would rather be in long, multi-paragraph docstrings. Then this
dilemma comes to me: if I am doing literate programming and I want to
explain in detail what the function x does, I write it in the main text
as part of the documentation. But also that explanation should be a
docstring, in the source file. I understand that the docstring would not
appear in the PDF (to avoid redundancy), but I don't know if it would be
a good practice either, since the docstring belongs to the code...
In short, my dilemma is: how to do good literate programming with a
language like Elisp, which is almost self-documenting in its code? (So
one can learn a lot about Elisp just by reading the code in the *.el
files, without going to the documentation (which is a great strength of
Elisp, by the way).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Docstrings and literate programming (good practices?)
2022-11-02 12:49 8% ` Juan Manuel Macías
@ 2022-11-02 13:05 5% ` Ihor Radchenko
2022-11-02 15:20 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-11-02 13:05 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> Why do you need to strip docstring on export?
>
> Thanks for the suggestion. The problem with doing it this way is that
> the paragraph is exported as verbatim, and I want it to be exported as a
> normal part of the text. For example, in a PDF or HTML it would say
> something like:
>
> ---
> This awesome function is for blah blah, and makes blah blah, when blah blah.
>
> [the function code]
> ---
Can you elaborate about "paragraph is exported as verbatim"?
> Actually I don't know if it's good practice to do it like this, hence my
> doubts about how to 'marry' the literate programming concept with
> languages that support docstring, which, somehow, are largely
> self-documenting (thanks to the existence of the docstring itself) . The
> scenario would rather be in long, multi-paragraph docstrings. Then this
> dilemma comes to me: if I am doing literate programming and I want to
> explain in detail what the function x does, I write it in the main text
> as part of the documentation. But also that explanation should be a
> docstring, in the source file. I understand that the docstring would not
> appear in the PDF (to avoid redundancy), but I don't know if it would be
> a good practice either, since the docstring belongs to the code...
>
> In short, my dilemma is: how to do good literate programming with a
> language like Elisp, which is almost self-documenting in its code? (So
> one can learn a lot about Elisp just by reading the code in the *.el
> files, without going to the documentation (which is a great strength of
> Elisp, by the way).
I'd do something like the following:
1. Use normal Org text for docstring marked with some kind of block
container (#+begin_docstring..#+end_docstring) or a dedicated
headline.
2. Extend Org with some fancy links specific to docstring. That way, the
original document can be read with active links to, say, other
functions and variables. (I think Doom is using something like this
for its new docs. Timothy is working on this)
3. Those links will be transformed to online documentation links on
normal export.
4. For docstrings, on tangle, the links will be processed via
`org-export-string-as' with a specialized backend that can escape
what is needed for the target language docstring and transform Org
links into whatever the docstring format is used for internal
docstring references.
5. For docstrings, on export, the noweb will generate something like
"[docstring is detailed in the text]", maybe even with a hyperlink to
the docstring in text.
Hope it makes sense.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Docstrings and literate programming (good practices?)
2022-11-02 13:05 5% ` Ihor Radchenko
@ 2022-11-02 15:20 8% ` Juan Manuel Macías
2022-11-03 7:38 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-02 15:20 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Can you elaborate about "paragraph is exported as verbatim"?
Sorry for the conciseness in my previous explanation. I meant something
like this:
: foo
is exported to LaTeX as
\begin{verbatim}
foo
\end{verbatim}
(and what i want is for it to be exported as 'normal text').
>> Actually I don't know if it's good practice to do it like this, hence my
>> doubts about how to 'marry' the literate programming concept with
>> languages that support docstring, which, somehow, are largely
>> self-documenting (thanks to the existence of the docstring itself) . The
>> scenario would rather be in long, multi-paragraph docstrings. Then this
>> dilemma comes to me: if I am doing literate programming and I want to
>> explain in detail what the function x does, I write it in the main text
>> as part of the documentation. But also that explanation should be a
>> docstring, in the source file. I understand that the docstring would not
>> appear in the PDF (to avoid redundancy), but I don't know if it would be
>> a good practice either, since the docstring belongs to the code...
>>
>> In short, my dilemma is: how to do good literate programming with a
>> language like Elisp, which is almost self-documenting in its code? (So
>> one can learn a lot about Elisp just by reading the code in the *.el
>> files, without going to the documentation (which is a great strength of
>> Elisp, by the way).
>
> I'd do something like the following:
> 1. Use normal Org text for docstring marked with some kind of block
> container (#+begin_docstring..#+end_docstring) or a dedicated
> headline.
> 2. Extend Org with some fancy links specific to docstring. That way, the
> original document can be read with active links to, say, other
> functions and variables. (I think Doom is using something like this
> for its new docs. Timothy is working on this)
> 3. Those links will be transformed to online documentation links on
> normal export.
> 4. For docstrings, on tangle, the links will be processed via
> `org-export-string-as' with a specialized backend that can escape
> what is needed for the target language docstring and transform Org
> links into whatever the docstring format is used for internal
> docstring references.
> 5. For docstrings, on export, the noweb will generate something like
> "[docstring is detailed in the text]", maybe even with a hyperlink to
> the docstring in text.
>
> Hope it makes sense.
I like the idea, because of the possibility of being able to use links.
That would also be respectful of the docstring as a legitimate part of
the code (in my approach, removing the docstring during export leaves an
empty line in the code, which is weird). Anyway, I think that with my
approach using org blocks and noweb references, links can also be used,
although more at a user/home-made level, with some export filter, I
suppose, that would convert the noweb reference into a normal link.
By the way, thinking about it, I don't know if a hypothetical header arg
called :docstring would be ok, something like:
#+NAME: foo
#+begin_<SPECIAL BLOCK NAME>
blah
#+end_<SPECIAL BLOCK NAME>
#+begin_src emacs-lisp :docstring foo
(defun foo ()
(message "hello world"))
#+end_src
And the docstring would be formatted and placed depending on the
language and the code (https://en.wikipedia.org/wiki/Docstring).
I don't know if something like this would make sense; although, thinking
about it, I like your idea of using special links better because it is
more versatile and (I guess) simpler to implement.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Docstrings and literate programming (good practices?)
2022-11-02 15:20 8% ` Juan Manuel Macías
@ 2022-11-03 7:38 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-11-03 7:38 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Can you elaborate about "paragraph is exported as verbatim"?
>
> Sorry for the conciseness in my previous explanation. I meant something
> like this:
>
> : foo
>
> is exported to LaTeX as
>
> \begin{verbatim}
> foo
> \end{verbatim}
>
> (and what i want is for it to be exported as 'normal text').
You can just
#+name: foo
foo
that will be exported with all the markup.
> By the way, thinking about it, I don't know if a hypothetical header arg
> called :docstring would be ok, something like:
>
> #+NAME: foo
> #+begin_<SPECIAL BLOCK NAME>
> blah
> #+end_<SPECIAL BLOCK NAME>
>
> #+begin_src emacs-lisp :docstring foo
> (defun foo ()
> (message "hello world"))
> #+end_src
>
> And the docstring would be formatted and placed depending on the
> language and the code (https://en.wikipedia.org/wiki/Docstring).
That's asking for too much. Supporting :docstring header argument in
such form will require babel backends to parse the code, which may not
be trivial. Or consider odd cases with polymorphic functions with the
same name.
However, note one past feature request about escaping text in noweb
references:
https://orgmode.org/list/82897e7d-f987-11f4-f7f5-fa1b8e462c0c@posteo.eu
Sébastien Miquel <sebastien.miquel@posteo.eu> (2021-05-03) (2021 emacs-orgmode.gnu.org maillist nolist)
Subject: [Feature request] String escaped noweb expansion
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Line breaks and brackets in LaTeX export
@ 2022-11-03 15:00 8% ` Juan Manuel Macías
2022-11-03 15:33 6% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-03 15:00 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> These arguments mean that auto-cleaning \\[0pt] is not always safe and
> may be a subject of surrounding LaTeX context. Moreover, there is no
> clear alternative to \\[0pt] that is guaranteed to work.
> Thus, the whole idea with cleaning up the generated LaTeX cannot be
> enabled by default, and I am not even sure if it is something we want to
> implement in the core.
>
> Juan, maybe you have some good alternative suggestions?
I'm afraid not. I've been trying to follow the thread these past few
days and frankly I can't think of anything beyond all the options that
have already been discussed.
I agree that the safest solution (or the least compromised, depending on
how we look at it) is to add [0pt] in all cases. I believe this should
not bring any unexpected consequences. At least I've tried all the
tabular environments related packages that I know of and there don't
seem to be any problems. And in the case of the verse package and verse
numberings, the solution is ad hoc with the patch that I have planned (I
hope to find a gap these days to finish it and test it...): The idea of
the patch is to replace the current separation between stanzas that Org
adds (\vspace) with a white line, and (only) in that case it would be
necessary to ensure that the last verse of the stanza ends in \\!.
On the other hand, if 'factory-cleaning' unnecessary instances of [0pt]
is going to be problematic, I also agree not to add that action to the
exporter. I think it would be better to leave these things up to the
users, depending on their use cases. After all, it is not difficult to
do it using a specific export filter. Maybe add some tips and examples
of basic filters in the documentation, especially for users who don't
have a lot of experience writing filters?
BTW, I also hope that one day this LaTeX problem, which has been there
for so many years, will be solved (because it should be considered a
LaTeX bug, or a LaTeX design flaw, as Maxim commented in another
message).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Line breaks and brackets in LaTeX export
2022-11-03 15:00 8% ` Juan Manuel Macías
@ 2022-11-03 15:33 6% ` Max Nikulin
2022-11-03 15:48 6% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Max Nikulin @ 2022-11-03 15:33 UTC (permalink / raw)
To: emacs-orgmode
> Ihor Radchenko writes:
>
>> These arguments mean that auto-cleaning \\[0pt] is not always safe and
>> may be a subject of surrounding LaTeX context.
I still believe that
something\\[0pt]%__ORG_EXPORT__
is quite safe to remove (depending on the following character) and
unlikely harmful if remained for some reason. Even tabularray
regexp-based parser ignores comments. To be perfect,
"\\[0pt]%__ORG_EXPORT__" emitted by user code should be escaped to e.g.
"\\[0pd]%__ORG_EXPORT____ORG_EXPORT__", but I have no idea if it can be
implemented in a reliable way.
An alternative is a new export framework.
On 03/11/2022 22:00, Juan Manuel Macías wrote:
>
> BTW, I also hope that one day this LaTeX problem, which has been there
> for so many years, will be solved (because it should be considered a
> LaTeX bug, or a LaTeX design flaw, as Maxim commented in another
> message).
I have not managed to convince even the tabularray developer. And I have
not tried to find a way to reach more LaTeX developers.
^ permalink raw reply [relevance 6%]
* Re: Line breaks and brackets in LaTeX export
2022-11-03 15:33 6% ` Max Nikulin
@ 2022-11-03 15:48 6% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-03 15:48 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> I have not managed to convince even the tabularray developer. And I
> have not tried to find a way to reach more LaTeX developers.
I think that people from the LaTeX team and the authors of the most
popular packages are often very active on tex.stackexchange.com
And the repo on GitHub for the LaTeX project: https://github.com/latex3
^ permalink raw reply [relevance 6%]
* Re: Docstrings and literate programming (good practices?)
2022-11-01 14:07 7% Docstrings and literate programming (good practices?) Juan Manuel Macías
2022-11-02 7:13 6% ` Ihor Radchenko
@ 2022-11-03 20:54 5% ` Rudolf Adamkovič
2022-11-04 3:03 0% ` Samuel Wales
1 sibling, 1 reply; 200+ results
From: Rudolf Adamkovič @ 2022-11-03 20:54 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
Hello Juan!
> I can duplicate the text, but it seems to be a bit redundant, right?
> So what is the best way to proceed when doing literate programming
> with any language that supports docstrings? Apologies in advance if
> the question is a bit silly, but I'm not a professional programmer and
> don't have an academic background in it, so I don't know if there is
> any good practice on these things :-)
A "bit silly" question? I find your question rather profound. Thank
you for bringing it up!
Personally, I recommend to use both docstrings and literate programming
idiomatically, not mixing them.
Literate programming exposes thinking and exploration.
For example, the literate portion can show different approaches you
tried but abandoned, something that does not belong to the function
itself, nor in its docstring. Or, it can include examples, piece-wise
performance analysis, computer science background, mathematical model,
citations of prior work, and so on. Add some assertions and you will
have literate tests as well.
A docstring describes the function from the outside, as a black box, and
if you did a good job with it, it makes it simpler for the consumer to
use your function.
Literate programming, on the other hand, goes deeper. It describes the
thinking that went into the function, comfortably exposing its insides
and opening the black box of its abstraction.
Rudy
--
"Strange as it may sound, the power of mathematics rests on its evasion
of all unnecessary thought and on its wonderful saving of mental
operations."
-- Ernst Mach, 1838-1916
Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia
^ permalink raw reply [relevance 5%]
* Re: Docstrings and literate programming (good practices?)
2022-11-03 20:54 5% ` Rudolf Adamkovič
@ 2022-11-04 3:03 0% ` Samuel Wales
0 siblings, 0 replies; 200+ results
From: Samuel Wales @ 2022-11-04 3:03 UTC (permalink / raw)
To: Rudolf Adamkovič; +Cc: Juan Manuel Macías, orgmode
i wonder if emacs or org has what you might call semi-literate or
etaretil docstring functions?
for example, you have a body of non-literate elisp code, and you have
a manual. it could be redundant to describe commands and what they do
and their options, if the docstrings are good.
why not include the docstrings of all commands in some nice format in
the .org manual via some mechanism?
would that be a good practice? seems useful abstractly.
On 11/3/22, Rudolf Adamkovič <salutis@me.com> wrote:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
> Hello Juan!
>
>> I can duplicate the text, but it seems to be a bit redundant, right?
>> So what is the best way to proceed when doing literate programming
>> with any language that supports docstrings? Apologies in advance if
>> the question is a bit silly, but I'm not a professional programmer and
>> don't have an academic background in it, so I don't know if there is
>> any good practice on these things :-)
>
> A "bit silly" question? I find your question rather profound. Thank
> you for bringing it up!
>
> Personally, I recommend to use both docstrings and literate programming
> idiomatically, not mixing them.
>
> Literate programming exposes thinking and exploration.
>
> For example, the literate portion can show different approaches you
> tried but abandoned, something that does not belong to the function
> itself, nor in its docstring. Or, it can include examples, piece-wise
> performance analysis, computer science background, mathematical model,
> citations of prior work, and so on. Add some assertions and you will
> have literate tests as well.
>
> A docstring describes the function from the outside, as a black box, and
> if you did a good job with it, it makes it simpler for the consumer to
> use your function.
>
> Literate programming, on the other hand, goes deeper. It describes the
> thinking that went into the function, comfortably exposing its insides
> and opening the black box of its abstraction.
>
> Rudy
> --
> "Strange as it may sound, the power of mathematics rests on its evasion
> of all unnecessary thought and on its wonderful saving of mental
> operations."
> -- Ernst Mach, 1838-1916
>
> Rudolf Adamkovič <salutis@me.com> [he/him]
> Studenohorská 25
> 84103 Bratislava
> Slovakia
>
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
^ permalink raw reply [relevance 0%]
* Re: Line breaks and brackets in LaTeX export
@ 2022-11-04 5:40 5% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-11-04 5:40 UTC (permalink / raw)
To: emacs-orgmode
On 04/11/2022 11:23, Ihor Radchenko wrote:
> Max Nikulin writes:
>>> Ihor Radchenko writes:
>>>
>>>> These arguments mean that auto-cleaning \\[0pt] is not always safe and
>>>> may be a subject of surrounding LaTeX context.
>>
>> I still believe that
>>
>> something\\[0pt]%__ORG_EXPORT__
>>
>> is quite safe to remove (depending on the following character) and
>> unlikely harmful if remained for some reason.
>
> What about the side effect you mentioned in a previous email?
>
>> TeX reads
>>
>> "a% comment
>> b"
>>
>> as "ab", dropping newline and starting spaces.
Unlike in Org, in TeX "a\\b" still contains a line break. Besides exotic
packages and user setups it should just work. After all, during normal
operation all "%__ORG_EXPORT__" should be stripped by a filter. They are
just marks where a decision is necessary whether to retain "[0pt]" or to
remove it.
On 03/11/2022 22:48, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
>> I have not managed to convince even the tabularray developer. And I
>> have not tried to find a way to reach more LaTeX developers.
>
> I think that people from the LaTeX team and the authors of the most
> popular packages are often very active on tex.stackexchange.com
Stackexchange is for questions, not for discussions and bugs. At certain
point I was going to ask a question there, I even prepared a draft.
After that I decided to try a command expanding to nothing and found
\empty. I was not aware that tabularray uses a different approach to
parsing.
> And the repo on GitHub for the LaTeX project: https://github.com/latex3
https://github.com/latex3/latex3/issues may be an appropriate place,
thank you.
^ permalink raw reply [relevance 5%]
* Re: Can :packages and :headers arguments in latex SRC blocks be made affect EXPORT blocks of results?
@ 2022-11-09 17:30 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-09 17:30 UTC (permalink / raw)
To: hugo; +Cc: emacs-orgmode
hugo@heagren.com writes:
> Is there a way around this? Either to export the src block another way,
> or to add metadata to the to the resulting EXPORT block (or just text,
> though I'm not sure how that would work for `:packages', since they
> require text to be added to the resulting exported LaTeX file in a
> different place from where the text of the block goes).
If I have understood correctly what you want to do, maybe a solution
would be this. You can starting from a single block that includes
the preamble for both preview and export:
#+NAME: preamble
#+begin_src latex :exports none
\usepackage{tikz}
\usetikzlibrary{calc,positioning,patterns}
#+end_src
This block returns the above as a simple string:
#+NAME: pre
#+begin_src emacs-lisp :exports none :results silent :var x = preamble
(with-temp-buffer
(insert x)
(LaTeX-mode)
(setq preamble-prev (buffer-string)))
#+end_src
And this one adds the necessary LaTeX headers when you export the
document, so LaTeX doesn't crash when compiling.
#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <<preamble>>
#+end_src
And the final block:
#+header: :results (if (org-export-derived-backend-p org-export-current-backend 'latex) "latex" "file raw")
#+header: :file (if (org-export-derived-backend-p org-export-current-backend 'latex) nil "foo.png")
#+header: :imagemagick t :fit t
#+header: :headers `(,(progn (org-babel-ref-resolve "pre") preamble-prev))
#+begin_src latex
\begin{tikzpicture}[on grid,
font=\footnotesize,
level distance=2.5cm,
sibling distance=2.5cm,
every node/.style={circle,draw,fill=white},
touch/.style={circle,draw=red!100,fill=red!40,thick},
invirtueof/.style={circle,draw=red!50,fill=red!20,very thick}]
\node [invirtueof] {Car}
child {node {wheel}}
child {node [invirtueof] {body}
child {node {driver door}}
child {node [invirtueof] {passenger door}
child {node [touch] {region of door}}}};
\end{tikzpicture}
#+end_src
#+RESULTS:
[[file:foo.png]]
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
@ 2022-11-10 12:40 9% ` Juan Manuel Macías
2022-11-11 2:04 4% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-10 12:40 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
Ihor Radchenko writes:
> I am trying to look into RTL language exports.
>
> I tried the following simple-minded Org file:
>
> #+title: Temp
> #+LATEX_COMPILER: lualatex
>
> #+LANGUAGE: HE
>
> \begin{equation}
> f(x) = \frac{8}{7}
> \end{equation}
>
> #+begin_src python :exports code
> for i in range(3):
> print("hello")
> #+end_src
>
> And exported to pdf (C-c C-e l o).
> Surprisingly, the output is in English.
>
> Am I missing something?
You need to explicitly load babel or polyglossia:
For polyglossia (`org-latex-guess-polyglossia-language'):
#+LaTeX_Header: \usepackage[AUTO]{polyglossia}
For babel (`org-latex-guess-babel-language'):
#+LaTeX_Header: \usepackage[bidi=basic]{babel}
#+LaTeX_Header: \babelprovide[import, main]{AUTO}
There was a discussion in an old thread about the possibility of loading
babel or polyglossia automatically (I think Maxim was in favor of it,
and brought up some possibilities). The problem is that babel's syntax
is somewhat more complex than polyglossia's, and admits many variants.
Also in babel there are languages that are loaded using the new ini file
system with the command \babelprovide. Currently,
org-latex-guess-babel-language supports babelprovide, but you need to
load the command explicitly:
#+LaTeX_Header: \babelprovide[options]{AUTO}
BTW I've noticed that the value of #+language is not case-agnostic. You
should put "he". Should it be case-agnostic? In the previous
implementation, when there were two language lists for babel and
polyglossia, neither was it.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-10 12:40 9% ` Juan Manuel Macías
@ 2022-11-11 2:04 4% ` Ihor Radchenko
2022-11-11 15:08 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-11-11 2:04 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> And exported to pdf (C-c C-e l o).
>> Surprisingly, the output is in English.
>>
>> Am I missing something?
>
> You need to explicitly load babel or polyglossia:
>
> For polyglossia (`org-latex-guess-polyglossia-language'):
>
> #+LaTeX_Header: \usepackage[AUTO]{polyglossia}
Aha! I missed that part in the newer manual.
Note that the manual only talks about setting
`org-latex-packages-alist'. Not the keyword.
Maybe we can add the #+LATEX_HEADER example to the manual.
> BTW I've noticed that the value of #+language is not case-agnostic. You
> should put "he". Should it be case-agnostic? In the previous
> implementation, when there were two language lists for babel and
> polyglossia, neither was it.
I think that it is a good idea. I do not recall common language
abbreviations to be case-sensitive in other software.
---------
Now, let me continue to act like an ordinary user and follow your
suggestion :)
I tried to add the header:
#+title: Temp
#+LATEX_COMPILER: lualatex
#+LANGUAGE: he
#+LaTeX_Header: \usepackage[AUTO]{polyglossia}
\begin{equation}
f(x) = \frac{8}{7}
\end{equation}
#+begin_src python :exports code
for i in range(3):
print("hello")
#+end_src
Then, C-c C-e l o
And I get an error...
Rc files read:
NONE
Latexmk: This is Latexmk, John Collins, 29 September 2020, version: 4.70b.
Rule 'lualatex': File changes, etc:
Changed files, or newly in use since previous run(s):
'bug.tex'
------------
Run number 1 of rule 'lualatex'
------------
------------
Running 'lualatex -interaction=nonstopmode -recorder -output-directory="." "bug.tex"'
------------
Set environment variable BIBINPUTS='.:'
Set environment variable TEXINPUTS='.:'
Latexmk: applying rule 'lualatex'...
This is LuaHBTeX, Version 1.13.0 (TeX Live 2021 Gentoo Linux)
restricted system commands enabled.
(./bug.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-02-18>
(/usr/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
[clipped]
(/usr/share/texmf-dist/tex/luatex/luatexbase/luatexbase.sty
(/usr/share/texmf-dist/tex/luatex/ctablestack/ctablestack.sty))
(/usr/share/texmf-dist/tex/latex/polyglossia/gloss-latex.ldf))
(/usr/share/texmf-dist/tex/latex/polyglossia/gloss-hebrew.ldf
! LaTeX Error: File `luabidi.sty' not found.
Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)
Enter file name:
! Emergency stop.
<read *>
l.3 \RequireBidi
440 words of node memory still in use:
3 hlist, 1 rule, 1 dir, 3 kern, 1 glyph, 4 attribute, 58 glue_spec, 4 attrib
ute_list, 1 if_stack, 1 write nodes
avail lists: 2:13,3:2,4:1,5:2,7:2,9:2
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on bug.log.
Latexmk: Missing input file: 'luabidi.sty' from line
'! LaTeX Error: File `luabidi.sty' not found.'
Failure to make 'bug.pdf'
Collected error summary (may duplicate other messages):
lualatex: Command for 'lualatex' gave return code 1
Refer to 'bug.log' for details
Latexmk: Examining 'bug.log'
=== TeX engine is 'LuaHBTeX'
Latexmk: Errors, in force_mode: so I tried finishing targets
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 4%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-11 2:04 4% ` Ihor Radchenko
@ 2022-11-11 15:08 8% ` Juan Manuel Macías
2022-11-13 4:09 3% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-11 15:08 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
Hi, Ihor,
I start by comment the error that you get when compiling. Is it possible
that you have an incomplete TeX Live installation? Distro repositories
usually offer TeX live in a modular way. On Arch Linux and its
derivatives, the texlive-lang and texlive-lang-extra packages should be
installed for non-Latin language support (this would include the luabidi
package). In the Ubuntu/Debian family I think the required package is
called texlive-lang-arabic. Anyway, I recommend installing TeX live in
its entirety (the drawback is that it takes up more space). I think that
in Ubuntu and family the meta-package is called texlive-full. Another
possibility that I recommend, especially on distros that package older
versions of TeX live, is to install the official TeX live distribution:
https://tug.org/texlive/acquire.html (this has the advantage of being
able to update everything more regularly via TeX live's own package
manager). If you want to keep the official packages of your distro, but
also want to try new things, it is also possible to create a portable
installation of TeX live on a pen drive:
https://tug.org/texlive/archive/portable-anchor.html
Ihor Radchenko writes:
> Aha! I missed that part in the newer manual.
>
> Note that the manual only talks about setting
> `org-latex-packages-alist'. Not the keyword.
>
> Maybe we can add the #+LATEX_HEADER example to the manual.
There are examples included in 'LaTeX header and sectioning structure'.
Perhaps it would be nice to add some more examples in the case of Bidi
languages, Chinese, Japanese, etc.? In the case of CJK languages, I
think additional LaTeX packages are required.
>> BTW I've noticed that the value of #+language is not case-agnostic. You
>> should put "he". Should it be case-agnostic? In the previous
>> implementation, when there were two language lists for babel and
>> polyglossia, neither was it.
>
> I think that it is a good idea. I do not recall common language
> abbreviations to be case-sensitive in other software.
>
I totally agree: that's something I missed when I made the previous
patch...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Help with a (query) replacement
@ 2022-11-12 15:10 10% ` Juan Manuel Macías
2022-11-12 15:12 7% ` Ypo
2022-11-12 15:23 12% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-12 15:10 UTC (permalink / raw)
To: Ypo; +Cc: Org-mode
Ypo writes:
> Hi
>
> I am copy-pasting e-books into org-mode to read and study them.
>
> Usually, words come hyphenated, like "ato- mized", that I wanted to
> transform into "atomized".
>
> I am trying with query replace, but I am starting to think that it is
> not the correct tool for this job.
> I tried "query-replace [a-z]-" but I don't know how to exclude the
> letter before the "-".
>
> What would you advise?
I think it will be more practical for you to use pandoc:
With this command you can convert an epub format to org:
pandoc my-epub.epub -o my.epub.org
(https://pandoc.org)
You can also install calibre and convert your epubs to plain text from
there.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Help with a (query) replacement
2022-11-12 15:10 10% ` Juan Manuel Macías
@ 2022-11-12 15:12 7% ` Ypo
2022-11-12 16:04 6% ` Juan Manuel Macías
2022-11-12 15:23 12% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ypo @ 2022-11-12 15:12 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Org-mode
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
Thanks, Juan Manuel.
I normally study using PDF books. Their typography is like "hardcoded",
so a post-processing using Orgmode is needed, I think.
El 12/11/2022 a las 16:10, Juan Manuel Macías escribió:
> Ypo writes:
>
>> Hi
>>
>> I am copy-pasting e-books into org-mode to read and study them.
>>
>> Usually, words come hyphenated, like "ato- mized", that I wanted to
>> transform into "atomized".
>>
>> I am trying with query replace, but I am starting to think that it is
>> not the correct tool for this job.
>> I tried "query-replace [a-z]-" but I don't know how to exclude the
>> letter before the "-".
>>
>> What would you advise?
> I think it will be more practical for you to use pandoc:
>
> With this command you can convert an epub format to org:
>
> pandoc my-epub.epub -o my.epub.org
>
> (https://pandoc.org)
>
> You can also install calibre and convert your epubs to plain text from
> there.
>
> Best regards,
>
> Juan Manuel
[-- Attachment #2: Type: text/html, Size: 1589 bytes --]
^ permalink raw reply [relevance 7%]
* Re: Help with a (query) replacement
2022-11-12 15:10 10% ` Juan Manuel Macías
2022-11-12 15:12 7% ` Ypo
@ 2022-11-12 15:23 12% ` Juan Manuel Macías
2022-11-12 15:25 6% ` Ypo
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-12 15:23 UTC (permalink / raw)
To: Ypo; +Cc: Org-mode
Juan Manuel Macías writes:
> I think it will be more practical for you to use pandoc:
>
> With this command you can convert an epub format to org:
>
> pandoc my-epub.epub -o my.epub.org
>
> (https://pandoc.org)
>
> You can also install calibre and convert your epubs to plain text from
> there.
PS: And you can also open epubs in Emacs with the nov.el package
(https://github.com/wasamasa/nov.el) and copy whatever text you want
from there.
^ permalink raw reply [relevance 12%]
* Re: Help with a (query) replacement
2022-11-12 15:23 12% ` Juan Manuel Macías
@ 2022-11-12 15:25 6% ` Ypo
0 siblings, 0 replies; 200+ results
From: Ypo @ 2022-11-12 15:25 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Org-mode
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
ummm, so you copy-paste from nov.el into an org buffer and then format
would be maintained... interesting.
Thanks
El 12/11/2022 a las 16:23, Juan Manuel Macías escribió:
> Juan Manuel Macías writes:
>
>> I think it will be more practical for you to use pandoc:
>>
>> With this command you can convert an epub format to org:
>>
>> pandoc my-epub.epub -o my.epub.org
>>
>> (https://pandoc.org)
>>
>> You can also install calibre and convert your epubs to plain text from
>> there.
> PS: And you can also open epubs in Emacs with the nov.el package
> (https://github.com/wasamasa/nov.el) and copy whatever text you want
> from there.
[-- Attachment #2: Type: text/html, Size: 1380 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Help with a (query) replacement
2022-11-12 15:12 7% ` Ypo
@ 2022-11-12 16:04 6% ` Juan Manuel Macías
2022-11-12 16:29 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-12 16:04 UTC (permalink / raw)
To: Ypo; +Cc: Org-mode
Ypo writes:
> Thanks, Juan Manuel.
>
> I normally study using PDF books. Their typography is like
> "hardcoded", so a post-processing using Orgmode is needed, I think.
If it's a PDF then forget what I told you about pandoc, because here
pandoc would have nothing to do. I thought you were referring to files
in epub format, sorry.
In the case of PDFs, I would use pdftotext. It converts the PDF to plain
text and (in theory) removes hyphens from the PDF after conversion. The
resulting plain text is somewhat ugly (page numbers and other elements
are preserved), but if you just want to copy/paste text, I think it's
enough.
The command:
pdftotext my-file.pdf
https://man.archlinux.org/man/pdftotext.1.en
https://en.wikipedia.org/wiki/Pdftotext
^ permalink raw reply [relevance 6%]
* Re: Help with a (query) replacement
2022-11-12 16:04 6% ` Juan Manuel Macías
@ 2022-11-12 16:29 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-12 16:29 UTC (permalink / raw)
To: Ypo; +Cc: Org-mode
Juan Manuel Macías writes:
> In the case of PDFs, I would use pdftotext. It converts the PDF to plain
> text and (in theory) removes hyphens from the PDF after conversion. The
> resulting plain text is somewhat ugly (page numbers and other elements
> are preserved), but if you just want to copy/paste text, I think it's
> enough.
And if you don't want to mess with the command line, you can also use
calibre here to convert from PDF to plain text or even Epub (the latter
is better because Epub is a tagged format and then you can have more
control over how to process that, for example by converting it to Org or
Markdown with pandoc). Calibre will do its best to preserve the
structure of the PDF, removing hyphens and other unnecessary elements.
But keep in mind that this process is largely heuristic, and the
conversion is not 100% perfect. However, it works acceptably well.
https://calibre-ebook.com/about
^ permalink raw reply [relevance 12%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-11 15:08 8% ` Juan Manuel Macías
@ 2022-11-13 4:09 3% ` Ihor Radchenko
2022-11-13 13:27 4% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-11-13 4:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I start by comment the error that you get when compiling. Is it possible
> that you have an incomplete TeX Live installation? Distro repositories
> usually offer TeX live in a modular way. On Arch Linux and its
> derivatives, the texlive-lang and texlive-lang-extra packages should be
> installed for non-Latin language support (this would include the luabidi
> package). In the Ubuntu/Debian family I think the required package is
> called texlive-lang-arabic. Anyway, I recommend installing TeX live in
> its entirety (the drawback is that it takes up more space). I think that
> in Ubuntu and family the meta-package is called texlive-full. Another
> possibility that I recommend, especially on distros that package older
> versions of TeX live, is to install the official TeX live distribution:
> https://tug.org/texlive/acquire.html (this has the advantage of being
> able to update everything more regularly via TeX live's own package
> manager). If you want to keep the official packages of your distro, but
> also want to try new things, it is also possible to create a portable
> installation of TeX live on a pen drive:
> https://tug.org/texlive/archive/portable-anchor.html
Thanks for the detailed explanation! We may put something similar (or
shorter) into the manual (maybe as a footnote).
On Gentoo, the required package is dev-texlive/texlive-langarabic.
However, installing the package is not yet enough!
With the same file, I am getting missing font errors:
Setting \if@calendar@hebrew
(/usr/share/texmf-dist/tex/latex/polyglossia/babel-hebrewalph.def)) (./bug.aux
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.19 \selectlanguage *{hebrew}
) (/usr/share/texmf-dist/tex/latex/base/ts1cmr.fd)
(/usr/share/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) (/usr/share/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
(/usr/share/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))
(/usr/share/texmf-dist/tex/latex/hyperref/nameref.sty
(/usr/share/texmf-dist/tex/latex/refcount/refcount.sty)
(/usr/share/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty))
(./bug.out) (./bug.out)
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.25 \begin{document}
(/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/usr/share/texmf-dist/tex/latex/amsfonts/umsb.fd)
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.28 \tableofcontents
(./bug.toc
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.1 \selectlanguage *{hebrew}
)
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.32 \end{equation}
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.34 \begin{verbatim}
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.34 \begin{verbatim}
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.38 \end{document}
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.38 \end{document}
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] (./bug.aux
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.19 \selectlanguage *{hebrew}
))
(see the transcript file for additional information)
537 words of node memory still in use:
6 hlist, 2 vlist, 2 rule, 2 glue, 4 kern, 1 glyph, 8 attribute, 61 glue_spec
, 8 attribute_list, 1 write nodes
avail lists: 2:132,3:70,4:3,5:46,6:14,7:406,8:20,9:104,10:2
</usr/share/texmf-dist/fonts/opentype/public/lm/lmmono10-regular.otf></usr/shar
e/texmf-dist/fonts/opentype/public/lm/lmroman10-regular.otf></usr/share/texmf-d
ist/fonts/opentype/public/lm/lmroman12-bold.otf></usr/share/texmf-dist/fonts/op
entype/public/lm/lmroman12-regular.otf></usr/share/texmf-dist/fonts/opentype/pu
blic/lm/lmroman17-regular.otf></usr/share/texmf-dist/fonts/type1/public/amsfont
s/cm/cmmi10.pfb></usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb
>
Output written on bug.pdf (1 page, 28185 bytes).
Transcript written on bug.log.
Latexmk: Log file says output to 'bug.pdf'
Latexmk: Summary of warnings from last run of *latex:
=====Latex reported missing or unavailable character(s).
=====See log file for details.
Collected error summary (may duplicate other messages):
lualatex: Command for 'lualatex' gave return code 1
Refer to 'bug.log' for details
Latexmk: Examining 'bug.log'
=== TeX engine is 'LuaHBTeX'
Latexmk: Errors, in force_mode: so I tried finishing targets
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 3%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-13 4:09 3% ` Ihor Radchenko
@ 2022-11-13 13:27 4% ` Juan Manuel Macías
2022-11-14 2:38 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-13 13:27 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
Ihor Radchenko writes:
> On Gentoo, the required package is dev-texlive/texlive-langarabic.
>
> However, installing the package is not yet enough!
>
> With the same file, I am getting missing font errors:
>
> Setting \if@calendar@hebrew
> (/usr/share/texmf-dist/tex/latex/polyglossia/babel-hebrewalph.def)) (./bug.aux
>
> ! Package polyglossia Error: The current latin font does not contain the "Hebr
> ew" script!
> (polyglossia) Please define \hebrewfont with \newfontfamily comm
> and.
hmm, yes, I forgot to mention it before... It is necessary to load a
font that has support for Hebrew script, via fontspec package, otherwise
it will return an error, both with Polyglossia and with Babel. It should
be added:
\usepackage{fontspec}
\setmainfont{FreeSerif}
FreeSerif would work, if we do the test with otfinfo:
┌────
│ otfinfo -s /path/to/FreeSerif.ttf
│
│ DFLT Default
│ arab Arabic
│ beng Bengali
│ bng2 Bengali v.2
│ copt Coptic
│ cyrl Cyrillic
│ dev2 Devanagari v.2
│ glag Glagolitic
│ goth Gothic
│ grek Greek
│ hano Hanunoo
│ hebr Hebrew
│ latn Latin
│ latn.NLD Latin/Dutch
│ latn.TRK Latin/Turkish
│ mlym Malayalam
│ taml Tamil
│ thai Thai
└────
The use of the fontspec package (https://www.ctan.org/pkg/fontspec) is
ubiquitous in LuaTeX or XeTeX as long as one wants to have control
over fonts and use extended languages and characters. LuaTeX and XeTeX
use by default (for debatable historical reasons[1]) a Unicode variant
of the Computern Modern font, which has limited language coverage. I
remember that it was commented in a previous thread the possibility of
offering (for example, through a series of variables), a minimum
coverage of fonts to ensure that the documents, at least, are compiled
well and are readable. The user could redefine those variables to use
their preferred fonts. Or have the option that this part of the
preamble is not created, to have full control. I remember that I
proposed this, but there were other interesting proposals. For
example, Timothy commented on the possibility of using fontsets.
In LuaTeX you can define fallback fonts at a low level, using
luaotfload, for example:
┌────
│ \directlua
│ {luaotfload.add_fallback
│ ("myfallback",
│ {
│ "freeserif:mode=harf;script=grek",
│ "freeserif:mode=harf;script=cyrl",
│ "freeserif:mode=harf;script=arab",
│ "freeserif:mode=harf;script=hebr",
│ }
│ )
│ }
│
│ \setmainfont{latinmodernroman}[RawFeature={fallback=myfallback}]
└────
In the example above, it is defined Free Serif as fallback font for
Cyrillic, Greek, Arabic and Hebrew scripts. And HarfBuzz is used as
the OpenType rendering engine. As an example, it is valid, although it
is still a typographical aberration, since Free Serif and Latin Modern
are incompatible by design. But that is already an aesthetic issue :-)
I think that doing something similar in Org would be a bit complicated,
since it would be necessary to guess what languages and scripts are used
in each document. But a number of basic variables like
’defaultromanfont’, ’defaultmonofont’, etc. could be enough. But leaving
the possibility for the user with advanced knowledge of LuaTeX or XeTeX
to have full control, since the configuration of fonts and languages can
become very complex and extensive in multilingual documents.
[1] My admiration for Donald Knuth is limitless, but in the case of the
Computern Modern font I think Knuth (IMHO) was not inspired. It is a
font with many design flaws, difficult to read on the screen. I
understand that it is hard to get rid of such a TeX hallmark as
Computern Modern, but it would be necessary, especially now that TeX
can use truetype and opentype fonts and metafont has been obsolete. The
CM font is also the reason why many people who have never used LaTeX
think that all LaTeX documents look alike.
^ permalink raw reply [relevance 4%]
* [PATCH] ox-latex: fix `org-latex-guess-babel-language'
@ 2022-11-14 22:46 9% Juan Manuel Macías
2022-11-15 1:54 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-14 22:46 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
If the user puts a string other than AUTO as an argument to
`\babelprovide', it gives an error when exporting. For example:
`#+LaTeX_Header: \babelprovide[<options>]{hebrew}'
I am attaching a patch to fix that behaviour.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-fix-org-latex-guess-babel-language.patch --]
[-- Type: text/x-patch, Size: 1450 bytes --]
From 6dcba41f58b355296c3cacf97be9508581e1a10a Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 14 Nov 2022 23:33:16 +0100
Subject: [PATCH] lisp/ox-latex.el: fix `org-latex-guess-babel-language'
* (org-latex-guess-babel-language): If the user puts a string other
than AUTO as an argument to `\babelprovide', it gives an error when
exporting. For example:
`#+LaTeX_Header: \babelprovide[onchar=ids,import]{hebrew}'
---
lisp/ox-latex.el | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 9bdb9fb63..095f6b51c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1669,12 +1669,13 @@ Return the new header."
(if (not (string-match "\\\\babelprovide\\[.*\\]{\\(.+\\)}" header))
header
(let ((prov (match-string 1 header)))
- (when (equal "AUTO" prov)
- (replace-regexp-in-string (format
- "\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
- (format "\\1\\2%s}"
- (or language language-ini-only))
- header t))))))
+ (if (equal "AUTO" prov)
+ (replace-regexp-in-string (format
+ "\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
+ (format "\\1\\2%s}"
+ (or language language-ini-only))
+ header t)
+ header)))))
(defun org-latex-guess-polyglossia-language (header info)
"Set the Polyglossia language according to the LANGUAGE keyword.
--
2.38.1
^ permalink raw reply related [relevance 9%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-14 2:38 5% ` Ihor Radchenko
@ 2022-11-14 22:25 8% ` Juan Manuel Macías
2022-11-15 2:46 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-14 22:25 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
Ihor Radchenko writes:
> However, the PDF (see the attached) is erroneous:
> 1. Title "Temp" is written RTL
> 2. Year and date (numbers!) are written RTL
> 3. The python code is written RTL!!
>
> Just the equation is rendered LTR as expected and the ordinary Hebrew
> text is rendered RTL.
I'd say that's expected behavior. Note that if you declare Hebrew as the
main language, the LaTeX classes (in this case article.cls) will put
whatever is necessary in Hebrew and use the Hebrew (and RTL) typographic
rules where necessary, and that includes the title, the date, and the
various literal strings as the table of contents, figure counters,
captions, etc.
To use Hebrew in another context, it would have to be declared as a
secondary language. The latest versions of Babel allow you to associate
languages to scripts when it comes to non-Latin alphabets (Cyrillic,
Greek, Arabic, etc.), and also to associate fonts. In this way it would
not be necessary to indicate the language explicitly by means of a
\selectlanguage{} or \foreignlanguage{}{}. For example, suppose that my
document has Spanish as its main language, but I also add parts in
Hebrew, which would be automatically recognized by Babel, by putting
this:
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \setmainfont{FreeSerif}
#+LaTeX_Header: \usepackage[AUTO,bidi=basic]{babel}
#+LaTeX_Header: \babelprovide[onchar=ids,import]{hebrew}
#+language: es
(...And curiously I just realized with this example that it is necessary
to fix `org-latex-guess-babel-language', because in the current state it
returns an error if a string other than AUTO is put as argument of
babelprovide. I'll open another thread to submit a patch to fix that).
>> The use of the fontspec package (https://www.ctan.org/pkg/fontspec) is
>> ubiquitous in LuaTeX or XeTeX as long as one wants to have control
>> over fonts and use extended languages and characters. LuaTeX and XeTeX
>> use by default (for debatable historical reasons[1]) a Unicode variant
>> of the Computern Modern font, which has limited language coverage. I
>> remember that it was commented in a previous thread the possibility of
>> offering (for example, through a series of variables), a minimum
>> coverage of fonts to ensure that the documents, at least, are compiled
>> well and are readable. The user could redefine those variables to use
>> their preferred fonts. Or have the option that this part of the
>> preamble is not created, to have full control. I remember that I
>> proposed this, but there were other interesting proposals. For
>> example, Timothy commented on the possibility of using fontsets.
>
> I hope that it can be implemented some day.
> For now, we should detail important things, like setting suitable font,
> in the manual.
Perhaps a FONTS item could be added in "LaTeX specific export settings"?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-13 13:27 4% ` Juan Manuel Macías
@ 2022-11-14 2:38 5% ` Ihor Radchenko
2022-11-14 22:25 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-11-14 2:38 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> ! Package polyglossia Error: The current latin font does not contain the "Hebr
>> ew" script!
>> (polyglossia) Please define \hebrewfont with \newfontfamily comm
>> and.
>
> hmm, yes, I forgot to mention it before... It is necessary to load a
> font that has support for Hebrew script, via fontspec package, otherwise
> it will return an error, both with Polyglossia and with Babel. It should
> be added:
>
> \usepackage{fontspec}
> \setmainfont{FreeSerif}
Ok. Now, I am at least able to get the pdf. Hooray! :)
#+title: Temp
#+LATEX_COMPILER: lualatex
#+LANGUAGE: he
#+LaTeX_Header: \usepackage[AUTO]{polyglossia}
#+LaTeX_Header: \setmainfont{FreeSerif}
\begin{equation}
f(x) = \frac{8}{7}
\end{equation}
#+begin_src python :exports code
for i in range(3):
print("hello")
#+end_src
However, the PDF (see the attached) is erroneous:
1. Title "Temp" is written RTL
2. Year and date (numbers!) are written RTL
3. The python code is written RTL!!
Just the equation is rendered LTR as expected and the ordinary Hebrew
text is rendered RTL.
[-- Attachment #2: bug.pdf --]
[-- Type: application/pdf, Size: 26980 bytes --]
[-- Attachment #3: Type: text/plain, Size: 1266 bytes --]
> The use of the fontspec package (https://www.ctan.org/pkg/fontspec) is
> ubiquitous in LuaTeX or XeTeX as long as one wants to have control
> over fonts and use extended languages and characters. LuaTeX and XeTeX
> use by default (for debatable historical reasons[1]) a Unicode variant
> of the Computern Modern font, which has limited language coverage. I
> remember that it was commented in a previous thread the possibility of
> offering (for example, through a series of variables), a minimum
> coverage of fonts to ensure that the documents, at least, are compiled
> well and are readable. The user could redefine those variables to use
> their preferred fonts. Or have the option that this part of the
> preamble is not created, to have full control. I remember that I
> proposed this, but there were other interesting proposals. For
> example, Timothy commented on the possibility of using fontsets.
I hope that it can be implemented some day.
For now, we should detail important things, like setting suitable font,
in the manual.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex: fix `org-latex-guess-babel-language'
2022-11-14 22:46 9% [PATCH] ox-latex: fix `org-latex-guess-babel-language' Juan Manuel Macías
@ 2022-11-15 1:54 6% ` Ihor Radchenko
2022-11-17 14:48 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-11-15 1:54 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> If the user puts a string other than AUTO as an argument to
> `\babelprovide', it gives an error when exporting. For example:
>
> `#+LaTeX_Header: \babelprovide[<options>]{hebrew}'
>
> I am attaching a patch to fix that behaviour.
Thanks!
Could you also add a test to testing/lisp/test-ox-latex.el?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-14 22:25 8% ` Juan Manuel Macías
@ 2022-11-15 2:46 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-11-15 2:46 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> However, the PDF (see the attached) is erroneous:
>> 1. Title "Temp" is written RTL
>> 2. Year and date (numbers!) are written RTL
>> 3. The python code is written RTL!!
>>
>> Just the equation is rendered LTR as expected and the ordinary Hebrew
>> text is rendered RTL.
>
> I'd say that's expected behavior. Note that if you declare Hebrew as the
> main language, the LaTeX classes (in this case article.cls) will put
> whatever is necessary in Hebrew and use the Hebrew (and RTL) typographic
> rules where necessary, and that includes the title, the date, and the
> various literal strings as the table of contents, figure counters,
> captions, etc.
I agree about year, title, and date. However, not the code. I'd expect
code snippets to use LTR by default. Maybe with an export flag to switch
to RTL.
> To use Hebrew in another context, it would have to be declared as a
> secondary language. The latest versions of Babel allow you to associate
> languages to scripts when it comes to non-Latin alphabets (Cyrillic,
> Greek, Arabic, etc.), and also to associate fonts. In this way it would
> not be necessary to indicate the language explicitly by means of a
> \selectlanguage{} or \foreignlanguage{}{}. For example, suppose that my
> document has Spanish as its main language, but I also add parts in
> Hebrew, which would be automatically recognized by Babel, by putting
> this:
>
> #+LaTeX_Header: \usepackage{fontspec}
> #+LaTeX_Header: \setmainfont{FreeSerif}
> #+LaTeX_Header: \usepackage[AUTO,bidi=basic]{babel}
> #+LaTeX_Header: \babelprovide[onchar=ids,import]{hebrew}
> #+language: es
Should we allow #+language to have multiple values like
#+language: es en ru uk
with first value defining primary language and the rest being secondary?
Also, what does bidi=basic do?
Finally, may it be useful to provide a syntax (affiliated keyword) that
will set a language for specific paragraph?
> Perhaps a FONTS item could be added in "LaTeX specific export settings"?
Do we have #+FONTS setting? I'd say that it is worth adding.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex: fix `org-latex-guess-babel-language'
2022-11-15 1:54 6% ` Ihor Radchenko
@ 2022-11-17 14:48 10% ` Juan Manuel Macías
2022-11-18 8:31 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-17 14:48 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi, Ihor, sorry for the late replay,
Ihor Radchenko writes:
>> If the user puts a string other than AUTO as an argument to
>> `\babelprovide', it gives an error when exporting. For example:
>>
>> `#+LaTeX_Header: \babelprovide[<options>]{hebrew}'
>>
>> I am attaching a patch to fix that behaviour.
>
> Thanks!
> Could you also add a test to testing/lisp/test-ox-latex.el?
I'm afraid I'm not going to be able to do it in the short term, because
these days I'm going through a serious family problem, my mother is
admitted to the hospital, and I don't think I'm going to have time to
attend to this list.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] ox-latex: fix `org-latex-guess-babel-language'
2022-11-17 14:48 10% ` Juan Manuel Macías
@ 2022-11-18 8:31 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-11-18 8:31 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Thanks!
>> Could you also add a test to testing/lisp/test-ox-latex.el?
>
> I'm afraid I'm not going to be able to do it in the short term, because
> these days I'm going through a serious family problem, my mother is
> admitted to the hospital, and I don't think I'm going to have time to
> attend to this list.
Sorry to hear this.
I applied your patch as is. It is anyway an improvement.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fcf63fb31
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Macro: exporting roman numerals formatted as small-caps
@ 2022-12-08 12:38 5% Carlos Martínez
0 siblings, 0 replies; 200+ results
From: Carlos Martínez @ 2022-12-08 12:38 UTC (permalink / raw)
To: emacs-orgmode
Hello everyone!,
I am working in a paper written in org mode. There are lots of roman
numerals referring to centuries. In Spanish, those are written in
roman numerals and small caps. I want to export my paper both to odt
and to LaTeX.
I found a macro by Juan Manuel Macías which helped me to export the
numerals surrounded by \textsc{} when exporting to pdf, but I struggle
to do the same when exporting to odt. This is the macro:
#+MACRO: sc (eval (if (org-export-derived-backend-p
org-export-current-backend 'latex) (concat "@@latex:\\textsc{@@" $1
"@@latex:}@@") (concat "@@odt:<text:span
text:style-name=\"T1\">@@"$1"@@odt:</text:span>@@")))
I want to achieve something like this: "When exporting to LaTeX (o
derived formats), surround the argument with \textsc{}; if any other
format [it will always be odt], do the same with the proper odt code.
Thanks everyone, and my apologies if this is a noob question (but I am
actually a noob).
Best regards
N.B.: I extracted the odt snippet looking at the contents.xml inside
the odt file.
^ permalink raw reply [relevance 5%]
* Re: LaTeX tutorial (focused on what Org exports) ??
@ 2023-01-02 18:31 5% ` William Denton
2023-01-03 3:25 0% ` David Masterson
0 siblings, 1 reply; 200+ results
From: William Denton @ 2023-01-02 18:31 UTC (permalink / raw)
To: David Masterson; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]
On 30 December 2022, Thomas S. Dye wrote:
> Org's latex exporter is exceptionally capable. AFAICT, it doesn't have
> practical limits on the LaTeX it produces, at least for my academic use case.
> I'm able to use all of the LaTeX packages I've ever wanted to use.
Me too, and the more I use Org with LaTeX, the more I'm seeing how I can use Org
as a way to organize a large publishing project: use literate programming and
export the LaTeX piece by piece, documenting what I'm doing; use source blocks
to run necessary code to prepare images or files before inclusion; and so on.
Using Org (simple markup plus some +latex_header lines) and exporting to LaTeX
is straightforward enough ... managing a project, with the LaTeX as code to be
generated, can get a lot more complicated, but on the other hand, Org makes that
kind of thing simpler. (Of course, anything involving LaTeX is bound to get
complicated pretty soon.)
I've learned a lot from several regulars on this mailing list, including Juan
Manuel Macías, who does remarkable work on dictionaries and translations.
Here's an example:
https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00348.html
Along with all the other recommendations, it's worth looking at the user guide
for the memoir class, which is great for books:
https://www.ctan.org/pkg/memoir
It'll be somewhere on your system as memman.pdf. I learned a lot about page
design and LaTeX from it.
Cheers,
Bill
--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada
^ permalink raw reply [relevance 5%]
* Re: LaTeX tutorial (focused on what Org exports) ??
2023-01-02 18:31 5% ` William Denton
@ 2023-01-03 3:25 0% ` David Masterson
0 siblings, 0 replies; 200+ results
From: David Masterson @ 2023-01-03 3:25 UTC (permalink / raw)
To: William Denton; +Cc: emacs-orgmode
William Denton <wtd@pobox.com> writes:
> On 30 December 2022, Thomas S. Dye wrote:
>
>> Org's latex exporter is exceptionally capable. AFAICT, it doesn't
>> have practical limits on the LaTeX it produces, at least for my
>> academic use case. I'm able to use all of the LaTeX packages I've
>> ever wanted to use.
>
> Me too, and the more I use Org with LaTeX, the more I'm seeing how I
> can use Org as a way to organize a large publishing project: use
> literate programming and export the LaTeX piece by piece, documenting
> what I'm doing; use source blocks to run necessary code to prepare
> images or files before inclusion; and so on.
>
> Using Org (simple markup plus some +latex_header lines) and exporting
> to LaTeX is straightforward enough ... managing a project, with the
> LaTeX as code to be generated, can get a lot more complicated, but on
> the other hand, Org makes that kind of thing simpler. (Of course,
> anything involving LaTeX is bound to get complicated pretty soon.)
>
> I've learned a lot from several regulars on this mailing list,
> including Juan Manuel Macías, who does remarkable work on dictionaries
> and translations. Here's an example:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00348.html
>
> Along with all the other recommendations, it's worth looking at the
> user guide for the memoir class, which is great for books:
>
> https://www.ctan.org/pkg/memoir
>
> It'll be somewhere on your system as memman.pdf. I learned a lot
> about page design and LaTeX from it.
I'll have to make time for this. Thanks.
--
David Masterson
^ permalink raw reply [relevance 0%]
* Re: Filter for HTML (cite) footnotes?
@ 2023-01-07 17:12 6% ` M. ‘quintus’ Gülker
0 siblings, 0 replies; 200+ results
From: M. ‘quintus’ Gülker @ 2023-01-07 17:12 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Dear all,
I ought to drive this thread to its completion. What I intend to do is
better covered by the new callback functions provided by citeproc-el:
<https://github.com/andras-simonyi/citeproc-el/issues/111>
-quintus
Am Dienstag, dem 08. März 2022 schrieb Juan Manuel Macías:
> M. ‘quintus’ Gülker writes:
>
>> That is, what I am after effectively, is post-processing the results
>> generated by org-cite resp. citeproc.el. I have names in my
>> bibliographic database like “Axel von Hellfeld”, which contain the
>> German name particle “von”. Some (not all) citation customs require
>> “von” to be abbreviated to “v.” so that the cited name becomes
>> “v. Hellfeld”. This is not possible with CSL, so I look for another
>> way to automate this during the export process.
>
> I see. Have you tried using `org-export-filter-final-output-functions'?
> You can try a find/replace function for the footnotes of final
> output. The drawback is that the scope here is broader and
> care should be taken with false positives...
>
> Best regards,
>
> Juan Manuel
--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland | kontakt@guelker.eu | O<
^ permalink raw reply [relevance 6%]
* Re: OS advice
@ 2023-01-07 22:22 7% ` Juan Manuel Macías
2023-01-07 22:28 7% ` Ypo
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-01-07 22:22 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Ypo writes:
> Hi
>
> Orgmode is sometimes desperately slow on my PC:
>
> Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz, 3100 Mhz
>
> (RAM) 4,00 GB
>
> I am running Windows 10, everything I use works OK, but Orgmode.
>
> Do you think that if I install a Linux OS, Orgmode would run fast? Any
> OS suggestion?
I've read somewhere that Emacs performance on windows tends to be slow,
but I can't assure you because the last windows I suffered was W98, and
at that time I didn't even use Emacs. According to the official GNU
Emacs website:
#+begin_quote
The reason for GNU Emacs's existence is to provide a powerful editor for
the GNU operating system. Versions of GNU, such as GNU/Linux, are the
primary platforms for Emacs development.
However, GNU Emacs includes support for some other systems that
volunteers choose to support.
[...]
#+end_quote
I don't know what specific performance problems you have with Emacs
under Windows, but you can post them on the Emacs-devel mailing list to
help improve Emacs performance on windows.
However, if you are not tied to windows for work reasons or for a
specific application, my recommendation is that you migrate to
GNU/Linux. But I also recommend that you try to avoid falling into the
clutches of distro hopping, at least to begin with :-). In general, any
of the popular distributions (Ubuntu, Fedora, etc.) is a good choice.
Even if you want the latest of the latest software, EndeavourOS is an
excellent derivative of Arch Linux (much better than Manjaro) with a
very simple graphical installer. Arch itself also has a graphical
installer, if you want to install it, but I would start with Endeavour.
In Linux you also have the possibility of installing light desktop
environments or window managers, which run well with the specifications
of your PC. Lxde and Lxqt are good options, they have openbox as a
window manager, which is robust and highly configurable. But if you
don't want to complicate your life, xfce is a good option. Or Plasma,
which despite being very attractive, I remember that it did not consume
too many resources. And later, if you want to come in the world of
tiling-style window managers, you have a vast territory to explore. I
was very comfortable with BSPWM for a long time, until I migrated to
EXWM (Emacs X Window Manager), which is what I've been using now for a
few years.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: OS advice
2023-01-07 22:22 7% ` Juan Manuel Macías
@ 2023-01-07 22:28 7% ` Ypo
0 siblings, 0 replies; 200+ results
From: Ypo @ 2023-01-07 22:28 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]
Wow! Thanks Juan Manuel!
El 07/01/2023 a las 23:22, Juan Manuel Macías escribió:
> Ypo writes:
>
>> Hi
>>
>> Orgmode is sometimes desperately slow on my PC:
>>
>> Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz, 3100 Mhz
>>
>> (RAM) 4,00 GB
>>
>> I am running Windows 10, everything I use works OK, but Orgmode.
>>
>> Do you think that if I install a Linux OS, Orgmode would run fast? Any
>> OS suggestion?
> I've read somewhere that Emacs performance on windows tends to be slow,
> but I can't assure you because the last windows I suffered was W98, and
> at that time I didn't even use Emacs. According to the official GNU
> Emacs website:
>
> #+begin_quote
>
> The reason for GNU Emacs's existence is to provide a powerful editor for
> the GNU operating system. Versions of GNU, such as GNU/Linux, are the
> primary platforms for Emacs development.
>
> However, GNU Emacs includes support for some other systems that
> volunteers choose to support.
>
> [...]
>
> #+end_quote
>
> I don't know what specific performance problems you have with Emacs
> under Windows, but you can post them on the Emacs-devel mailing list to
> help improve Emacs performance on windows.
>
> However, if you are not tied to windows for work reasons or for a
> specific application, my recommendation is that you migrate to
> GNU/Linux. But I also recommend that you try to avoid falling into the
> clutches of distro hopping, at least to begin with :-). In general, any
> of the popular distributions (Ubuntu, Fedora, etc.) is a good choice.
> Even if you want the latest of the latest software, EndeavourOS is an
> excellent derivative of Arch Linux (much better than Manjaro) with a
> very simple graphical installer. Arch itself also has a graphical
> installer, if you want to install it, but I would start with Endeavour.
> In Linux you also have the possibility of installing light desktop
> environments or window managers, which run well with the specifications
> of your PC. Lxde and Lxqt are good options, they have openbox as a
> window manager, which is robust and highly configurable. But if you
> don't want to complicate your life, xfce is a good option. Or Plasma,
> which despite being very attractive, I remember that it did not consume
> too many resources. And later, if you want to come in the world of
> tiling-style window managers, you have a vast territory to explore. I
> was very comfortable with BSPWM for a long time, until I migrated to
> EXWM (Emacs X Window Manager), which is what I've been using now for a
> few years.
>
> Best regards,
>
> Juan Manuel
[-- Attachment #2: Type: text/html, Size: 3055 bytes --]
^ permalink raw reply [relevance 7%]
* Re: [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated
@ 2023-03-05 11:12 5% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2023-03-05 11:12 UTC (permalink / raw)
To: emacs-orgmode
On 18/02/2023 17:18, Ihor Radchenko wrote:
> In https://orgmode.org/worg/org-faq.html#org60202b9, the answer uses
> obsolete function `org-add-link-type'. We should change it to
> `org-link-set-parameters'.
Confirmed.
A newer recipe:
Juan Manuel Macías to emacs-orgmode… Re: how to export red colored TeX
to latex. Tue, 30 Nov 2021 16:56:00 +0000.
https://list.orgmode.org/87bl21vazj.fsf@posteo.net
Likely should be modified a bit to support derived backends.
The following package might be mentioned:
Colours section in org-special-block-extras
https://alhassy.com/org-special-block-extras/#Colours
Other files:
- org-tutorials/org-R/org-variables-counts.org
- org-tutorials/org-R/variable-popcon.org
Need review:
- org-hacks.org
mid: links for org-gnus (not ol-gnus) and org-occur example
- exporters/anno-bib-template-worg.org
citations using ebib
Outdated:
- org-tutorials/org-latex-export.org
Org < 8.0
- org-configs/org-customization-survey.org
- org-configs/org-customization-survey-2013.org
^ permalink raw reply [relevance 5%]
* Re: how to add special glyphs
@ 2023-03-07 15:54 6% ` Max Nikulin
2023-03-08 0:29 0% ` Rob Sargent
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-03-07 15:54 UTC (permalink / raw)
To: Rob Sargent, emacs-orgmode
On 06/03/2023 22:42, Rob Sargent wrote:
> I have added a "boxed x" and "CHECK MARK" to my document, but they do
> not get exported to pdf output.
LuaLaTeX may be instructed to use fallback fonts, see e.g.
https://list.orgmode.org/87bktus666.fsf_-_@posteo.net/
Juan Manuel Macías. Fallback fonts in LuaTeX via
'luaotfload.add_fallback' (was "Fontsets"). Tue, 12 Jul 2022 15:26:57 +0000
https://list.orgmode.org/orgmode/scuirf$m7o$1@ciao.gmane.io/
Maxim Nikulin. Re: org-mode export to (latex) PDF. Sat, 17 Jul 2021
19:35:57 +0700
To my taste it is too low level.
^ permalink raw reply [relevance 6%]
* Re: how to add special glyphs
2023-03-07 15:54 6% ` Max Nikulin
@ 2023-03-08 0:29 0% ` Rob Sargent
0 siblings, 0 replies; 200+ results
From: Rob Sargent @ 2023-03-08 0:29 UTC (permalink / raw)
To: emacs-orgmode
On 3/7/23 08:54, Max Nikulin wrote:
> On 06/03/2023 22:42, Rob Sargent wrote:
>> I have added a "boxed x" and "CHECK MARK" to my document, but they do
>> not get exported to pdf output.
>
> LuaLaTeX may be instructed to use fallback fonts, see e.g.
>
> https://list.orgmode.org/87bktus666.fsf_-_@posteo.net/
> Juan Manuel Macías. Fallback fonts in LuaTeX via
> 'luaotfload.add_fallback' (was "Fontsets"). Tue, 12 Jul 2022 15:26:57
> +0000
>
> https://list.orgmode.org/orgmode/scuirf$m7o$1@ciao.gmane.io/
> Maxim Nikulin. Re: org-mode export to (latex) PDF. Sat, 17 Jul 2021
> 19:35:57 +0700
>
> To my taste it is too low level.
That I placed the unicode into the text was "too low level"? I could
argue that "it's a UTF doc", or that "\ding{55}" is bizarrely high
level. Other's have shown methods which maximize the cross export
experience. I'll consider those. I'm not sure LuaLaTex is an option
for me.
rjs
^ permalink raw reply [relevance 0%]
* Re: How to tell `org-html-link' to create a link with some HTML class?
@ 2023-06-20 16:30 5% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2023-06-20 16:30 UTC (permalink / raw)
To: emacs-orgmode
On 20/06/2023 11:42, Marcin Borkowski wrote:
>
> as I mentioned some time ago, I'm writing a custom exporter (actually,
> a very thin wrapper around the HTML exporter). I'd like `org-html-link'
> to add some class to the links it generates. Is that possible?
I do not have a ready to use recipe. Some links to mailing list threads:
https://list.orgmode.org/t8q71r$mgv$1@ciao.gmane.io/
Max Nikulin. [BUG] manual: confusing example of adding attributes to a
link (affiliated keywords) Mon, 20 Jun 2022 23:25:29 +0700
Unfortunately
#+attr_html: :class something
adds class to the whole following paragraph as well. Notice a link to a
John Kitchin blog post. Another thread with the same link:
https://list.orgmode.org/87im8k3be8.fsf@posteo.net/
Juan Manuel Macías. Re: [tip] Export subfigures to LaTeX (and HTML).
Tue, 29 Dec 2020 16:00:31 +0100
I have not tried to implement an idea with a parse-tree export filter
that transfers attributes from links having a custom type to following
objects (Ihor is against such approach):
Max Nikulin. Re: About 'inline special blocks' Tue, 24 May 2022 22:09:33
+0700. https://list.orgmode.org/t6isfe$c50$1@ciao.gmane.io
^ permalink raw reply [relevance 5%]
* [patch] Fix inner smart quotes in French
@ 2023-08-04 7:25 12% Juan Manuel Macías
2023-08-04 11:09 6% ` Bastien
2023-08-05 7:08 6% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-04 7:25 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
Hi,
These last months I have been disconnected from the list for family
reasons. Now, trying to catch up with the news on the list and pending
things that I left here :-).
In the meantime, I'm submitting this patch with a fix for second-level
French `smart quotes': the correct quotes should be “” (without spaces,
as in Spanish or Greek) (please, some francophone correct me, if I'm
wrong...).
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Attachment #2: 0001-lisp-ox.el-fix-inner-smart-quotes-in-French.patch --]
[-- Type: text/x-patch, Size: 1195 bytes --]
From 202a085ce9e0e3e7c0e67bcdde91e706050fd976 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 4 Aug 2023 09:04:03 +0200
Subject: [PATCH] lisp/ox.el: fix inner smart quotes in French.
* (org-export-smart-quotes-alist): the correct French second level
quotation marks are added.
---
lisp/ox.el | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index 3a6dd8ded..473bd927c 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5840,11 +5840,8 @@ transcoding it."
(primary-closing
:utf-8 " »" :html " »" :latex "\\fg{}"
:texinfo "@tie{}@guillemetright{}")
- (secondary-opening
- :utf-8 "« " :html "« " :latex "\\og "
- :texinfo "@guillemetleft{}@tie{}")
- (secondary-closing :utf-8 " »" :html " »" :latex "\\fg{}"
- :texinfo "@tie{}@guillemetright{}")
+ (secondary-opening :utf-8 "“" :html "“" :latex "``" :texinfo "``")
+ (secondary-closing :utf-8 "”" :html "”" :latex "''" :texinfo "''")
(apostrophe :utf-8 "’" :html "’"))
("is"
(primary-opening
--
2.41.0
^ permalink raw reply related [relevance 12%]
* Re: [patch] Fix inner smart quotes in French
2023-08-04 7:25 12% [patch] Fix inner smart quotes in French Juan Manuel Macías
@ 2023-08-04 11:09 6% ` Bastien
2023-08-10 14:10 0% ` Max Nikulin
2023-08-05 7:08 6% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Bastien @ 2023-08-04 11:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> In the meantime, I'm submitting this patch with a fix for second-level
> French `smart quotes': the correct quotes should be “” (without spaces,
> as in Spanish or Greek) (please, some francophone correct me, if I'm
> wrong...).
Applied, thanks!
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [patch] Fix inner smart quotes in French
2023-08-04 7:25 12% [patch] Fix inner smart quotes in French Juan Manuel Macías
2023-08-04 11:09 6% ` Bastien
@ 2023-08-05 7:08 6% ` Ihor Radchenko
2023-08-05 10:51 12% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-05 7:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> These last months I have been disconnected from the list for family
> reasons. Now, trying to catch up with the news on the list and pending
> things that I left here :-).
Welcome back :)
> In the meantime, I'm submitting this patch with a fix for second-level
> French `smart quotes': the correct quotes should be “” (without spaces,
> as in Spanish or Greek) (please, some francophone correct me, if I'm
> wrong...).
The patch does not update the tests. So, we now have
FAILED 644/1151 test-org-export/activate-smart-quotes
And it looks like at least on of the test conditions is not trivial to
fix without knowing French. May you or somebody familiar with French
punctuation take a look?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Fix inner smart quotes in French
2023-08-05 7:08 6% ` Ihor Radchenko
@ 2023-08-05 10:51 12% ` Juan Manuel Macías
2023-08-05 13:19 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-05 10:51 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi, Ihor,
Ihor Radchenko writes:
> Welcome back :)
thanks! :-)
>> In the meantime, I'm submitting this patch with a fix for second-level
>> French `smart quotes': the correct quotes should be “” (without spaces,
>> as in Spanish or Greek) (please, some francophone correct me, if I'm
>> wrong...).
>
> The patch does not update the tests. So, we now have
> FAILED 644/1151 test-org-export/activate-smart-quotes
>
> And it looks like at least on of the test conditions is not trivial to
> fix without knowing French. May you or somebody familiar with French
> punctuation take a look?
I'm afraid I'm not very familiar with the syntax and usage of tests, so
I have to study that part. I've been looking at
`test-org-export/activate-smart-quotes', and I have a question: does it
only include tests for English and French cases?
First level quotes for French are «» with spaces, and second level ones
(if I'm not mistaken) should be “”, without spaces (my patch fix).
Therefore, I understand that a line like:
(equal '( "« outer « inner » outer »")
should it be changed like this
(equal '( "« outer “inner” outer »")
?
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: [patch] Fix inner smart quotes in French
2023-08-05 10:51 12% ` Juan Manuel Macías
@ 2023-08-05 13:19 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-08-05 13:19 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> And it looks like at least on of the test conditions is not trivial to
>> fix without knowing French. May you or somebody familiar with French
>> punctuation take a look?
>
> I'm afraid I'm not very familiar with the syntax and usage of tests, so
> I have to study that part. I've been looking at
> `test-org-export/activate-smart-quotes', and I have a question: does it
> only include tests for English and French cases?
Yes, currently.
> First level quotes for French are «» with spaces, and second level ones
> (if I'm not mistaken) should be “”, without spaces (my patch fix).
> Therefore, I understand that a line like:
>
> (equal '( "« outer « inner » outer »")
>
> should it be changed like this
>
> (equal '( "« outer “inner” outer »")
>
> ?
That was exactly the piece of information I was missing.
I have no notion of "inner" quotes being different from "outer" in the
languages I am familiar with.
I now managed to fix the tests.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e4f127437
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* [patch] ox-latex.el: fix blank lines behavior in verse block
@ 2023-08-06 12:03 8% Juan Manuel Macías
2023-08-07 11:40 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-06 12:03 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 3441 bytes --]
Rationale for this patch: the treatment of blank lines in
`org-latex-verse-block' is inconsistent with the syntax of the `verse'
environment, both the one that includes LaTeX and the one provided by
the `verse' package as a replacement for the former.
Currently, each blank line is exported to LaTeX as an explicit vertical
space: \vspace*{1em}. This can return unexpected results. For example,
this:
┌────
│ #+begin_verse
│
│ lorem
│ ipsum
│ dolor
|
│ #+end_verse
└────
is exported to LaTeX as:
┌────
│ \begin{verse}
│ \vspace*{1em}
│ lorem\\[0pt]
│ ipsum\\[0pt]
│ dolor\\[0pt]
│ \vspace*{1em}
│ \end{verse}
└────
In the LaTeX `verse' environment, spaces before and after the content
are not taken into account.
As for the separation between stanzas, this is marked with at least one
blank line between the stanzas, as in normal paragraphs (not with an
explicit vertical space). Also it is not necessar y that the last verse
of each stanza ends with the linebreak mark `\\'.
So, after this patch:
• Any blank line before and/or after the content is removed;
• One or more blank lines between stanzas are exported as a single blank
line, leaving the previous final verse without the linebreak mark
`\\';
• When verse numbering is enabled via the `:lines' attribute (for the
`verse' package), the last verses of each stanza are marked with
`\\!', according to the verse package syntax (this was not necessary
with the previous behavior).
This way, the `verse' block is exported to LaTeX with the correct
syntax. This also brings the advantage of being able to globally control
the spacing between stanzas via the verse package’s \stanzaskip command.
Example:
┌────
│ #+begin_verse
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│ #+end_verse
└────
LaTeX:
┌────
│ \begin{verse}
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ \end{verse}
└────
And with verse numbers:
┌────
│ #+ATTR_LaTeX: :lines 5
│ #+begin_verse
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│ #+end_verse
└────
LaTeX:
┌────
│ \begin{verse}
│ \poemlines{5}
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\!
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\!
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ \end{verse}
│ \poemlines{0}
└────
N.B.: the `\\[0pt]' mark of the last verse does not affect the final result.
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-fix-blank-lines-behavior-in-verse-b.patch --]
[-- Type: text/x-patch, Size: 1944 bytes --]
From 0c8a352567333d0d743b5235b68e9cd5d513f615 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 6 Aug 2023 12:42:36 +0200
Subject: [PATCH] lisp/ox-latex.el: fix blank lines behavior in verse block
export.
* (org-latex-verse-block): now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package.
---
lisp/ox-latex.el | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..26827537a 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4128,20 +4128,28 @@ contextual information."
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.
+ ;; into a space of 1 em. One or more blank lines between lines
+ ;; are exported as a single blank line.
(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
- (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")
- "\\vspace*{1em}"
+ (concat "\\("
+ (regexp-quote org-latex-line-break-safe)
+ "\n\\)"
+ "\\(^[ \t]*"
+ (regexp-quote org-latex-line-break-safe)
+ "\n"
+ "\\)+")
+ (if lin "\\\\!\n\n" "\n\n")
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n"
(concat org-latex-line-break-safe "\n")
- contents nil t)
+ ;; Remove any blank lines before and after CONTENTS.
+ (concat (org-trim contents t) "\n")
+ nil t)
nil t)
nil t)
linreset)
--
2.41.0
^ permalink raw reply related [relevance 8%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-06 12:03 8% [patch] ox-latex.el: fix blank lines behavior in verse block Juan Manuel Macías
@ 2023-08-07 11:40 6% ` Ihor Radchenko
2023-08-07 17:23 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-07 11:40 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Rationale for this patch: the treatment of blank lines in
> `org-latex-verse-block' is inconsistent with the syntax of the `verse'
> environment, both the one that includes LaTeX and the one provided by
> the `verse' package as a replacement for the former.
> ...
> So, after this patch:
>
> • Any blank line before and/or after the content is removed;
>
> • One or more blank lines between stanzas are exported as a single blank
> line, leaving the previous final verse without the linebreak mark
> `\\';
>
> • When verse numbering is enabled via the `:lines' attribute (for the
> `verse' package), the last verses of each stanza are marked with
> `\\!', according to the verse package syntax (this was not necessary
> with the previous behavior).
I see nothing that would prevent merging this patch.
However, I believe that removing blank lines before/after content is
something we may want to do in other built-in backends as well. WDYT?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-07 11:40 6% ` Ihor Radchenko
@ 2023-08-07 17:23 9% ` Juan Manuel Macías
2023-08-09 7:57 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-07 17:23 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> Rationale for this patch: the treatment of blank lines in
>> `org-latex-verse-block' is inconsistent with the syntax of the `verse'
>> environment, both the one that includes LaTeX and the one provided by
>> the `verse' package as a replacement for the former.
>> ...
>> So, after this patch:
>>
>> • Any blank line before and/or after the content is removed;
>>
>> • One or more blank lines between stanzas are exported as a single blank
>> line, leaving the previous final verse without the linebreak mark
>> `\\';
>>
>> • When verse numbering is enabled via the `:lines' attribute (for the
>> `verse' package), the last verses of each stanza are marked with
>> `\\!', according to the verse package syntax (this was not necessary
>> with the previous behavior).
>
> I see nothing that would prevent merging this patch.
> However, I believe that removing blank lines before/after content is
> something we may want to do in other built-in backends as well. WDYT?
I think you're right. My impression is that the blank lines before/after
content is not a desired feature, but rather a consequence of
substituting line breaks to create the space between stanzas. I think
the space before/after is better removed because it doesn't make sense
and adds unnecessary direct formatting[1]. Maybe it could be changed to
`(org-trim contents t) in all cases, like in this patch?
[1] However, the horizontal 'verbatim' space that can be added before
each line/verse seems like a great feature to me, since verses can also
be indented arbitrarily. This block it's a gem, and it has some really
cool features, not just to quote poetry.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-07 17:23 9% ` Juan Manuel Macías
@ 2023-08-09 7:57 6% ` Ihor Radchenko
2023-08-09 8:41 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-09 7:57 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> I see nothing that would prevent merging this patch.
>> However, I believe that removing blank lines before/after content is
>> something we may want to do in other built-in backends as well. WDYT?
>
> I think you're right. My impression is that the blank lines before/after
> content is not a desired feature, but rather a consequence of
> substituting line breaks to create the space between stanzas.
Do you mean that people use extra leading/trailing spaces just to get
extra vertical space before/after the verse block in _latex_ export?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-09 7:57 6% ` Ihor Radchenko
@ 2023-08-09 8:41 12% ` Juan Manuel Macías
2023-08-10 9:27 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-09 8:41 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>>> I see nothing that would prevent merging this patch.
>>> However, I believe that removing blank lines before/after content is
>>> something we may want to do in other built-in backends as well. WDYT?
>>
>> I think you're right. My impression is that the blank lines before/after
>> content is not a desired feature, but rather a consequence of
>> substituting line breaks to create the space between stanzas.
>
> Do you mean that people use extra leading/trailing spaces just to get
> extra vertical space before/after the verse block in _latex_ export?
No, I don't think people use it for that purpose. I meant that if
someone puts a space before or after the content (which can be usual,
for clarity):
#+begin_verse
blah...
#+end_verse
that vertical space appears in the export, which shouldn't.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-09 8:41 12% ` Juan Manuel Macías
@ 2023-08-10 9:27 5% ` Ihor Radchenko
2023-08-10 10:39 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-10 9:27 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Do you mean that people use extra leading/trailing spaces just to get
>> extra vertical space before/after the verse block in _latex_ export?
>
> No, I don't think people use it for that purpose. I meant that if
> someone puts a space before or after the content (which can be usual,
> for clarity):
>
> #+begin_verse
>
> blah...
>
> #+end_verse
>
> that vertical space appears in the export, which shouldn't.
Well. Technically, we already warn users that the blank lines are
preserved in the verse blocks:
12.1 Paragraphs
===============
Paragraphs are separated by at least one empty line. If you need to
enforce a line break within a paragraph, use ‘\\’ at the end of a line.
To preserve the line breaks, indentation and blank lines in a region,
but otherwise use normal formatting, you can use this construct, which
can also be used to format poetry.
#+BEGIN_VERSE
Great clouds overhead
Tiny black birds rise and fall
Snow covers Emacs
---AlexSchroeder
#+END_VERSE
So, I now think that while extra cleanups might be OK for ox-latex, we
may not want to ignore empty lines universally in all the verse blocks.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-10 9:27 5% ` Ihor Radchenko
@ 2023-08-10 10:39 10% ` Juan Manuel Macías
2023-08-11 10:00 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-10 10:39 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Well. Technically, we already warn users that the blank lines are
> preserved in the verse blocks:
>
> 12.1 Paragraphs
> ===============
>
> Paragraphs are separated by at least one empty line. If you need to
> enforce a line break within a paragraph, use ‘\\’ at the end of a line.
>
> To preserve the line breaks, indentation and blank lines in a region,
> but otherwise use normal formatting, you can use this construct, which
> can also be used to format poetry.
>
>
> #+BEGIN_VERSE
> Great clouds overhead
> Tiny black birds rise and fall
> Snow covers Emacs
>
> ---AlexSchroeder
> #+END_VERSE
>
> So, I now think that while extra cleanups might be OK for ox-latex, we
> may not want to ignore empty lines universally in all the verse blocks.
hmm, I don't know if phrased like that (as read in the documentation)
it's clear enough that the empty lines before and after the content are
also preserved. I would understand not, but it could also be a habit that
I inherited from LaTeX: I usually leave a blank line between the
#+begin/#+end directives and the content because it makes it easier for
me to read. I don't know if it is a widespread habit among other
users...
Anyway, I don't mind leaving things as they are in the other backends,
but in the case of LaTeX, with my patch modifications, it would be
necessary to remove the blank lines before and after the content.
Otherwise it would produce something like:
\begin{verse}
\\[0pt]
\\[0pt]
\\[0pt]
\\[0pt]
\\[0pt]
lorem ipsum dolor
\end{verse}
which would return the error "There's no line here to end".
Also, the LaTeX 'verse' environment has its own syntax for vertical
spaces. It is not necessary to put an explicit \vspace just to separate
stanzas.
... In any case, the fact that the verse block can also be used to
literally export line breaks and horizontal/vertical spaces is
interesting. Something occurred to me that I don't know if it's a bit
foolhardy: how about a LaTeX attribute ':literal t'? If used, it would
not export to a verse environment (specialized in poetry) but to normal
text, without environment, but with line breaks and horizontal and
vertical spacing preserved... wdyt?
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] Fix inner smart quotes in French
2023-08-04 11:09 6% ` Bastien
@ 2023-08-10 14:10 0% ` Max Nikulin
2023-08-10 14:49 0% ` Bastien
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-08-10 14:10 UTC (permalink / raw)
To: Bastien, Juan Manuel Macías; +Cc: orgmode
On 04/08/2023 18:09, Bastien wrote:
> Juan Manuel Macías writes:
>
>> In the meantime, I'm submitting this patch with a fix for second-level
>> French `smart quotes': the correct quotes should be “” (without spaces,
>> as in Spanish or Greek) (please, some francophone correct me, if I'm
>> wrong...).
>
> Applied, thanks!
I am not a francophone, I just have tried to look into sources I found
during discussion on Greek quotes.
https://en.wikipedia.org/wiki/Quotation_mark#French
says that there are different styles of inner quotes.
I am more worry that Unicode CLDR defines the same character for quotes.
However inner quotes varies across languages:
fr.xml: <quotationStart>«</quotationStart>
fr.xml: <quotationEnd>»</quotationEnd>
fr.xml: <alternateQuotationStart>«</alternateQuotationStart>
fr.xml: <alternateQuotationEnd>»</alternateQuotationEnd>
fr_CA.xml: <alternateQuotationStart>”</alternateQuotationStart>
fr_CA.xml: <alternateQuotationEnd>“</alternateQuotationEnd>
fr_CH.xml: <alternateQuotationStart>‹</alternateQuotationStart>
fr_CH.xml: <alternateQuotationEnd>›</alternateQuotationEnd>
I would prefer to keep consistency with CLDR.
^ permalink raw reply [relevance 0%]
* Re: [patch] Fix inner smart quotes in French
2023-08-10 14:10 0% ` Max Nikulin
@ 2023-08-10 14:49 0% ` Bastien
2023-08-10 21:50 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Bastien @ 2023-08-10 14:49 UTC (permalink / raw)
To: Max Nikulin; +Cc: Juan Manuel Macías, orgmode
Max Nikulin <manikulin@gmail.com> writes:
> On 04/08/2023 18:09, Bastien wrote:
>> Juan Manuel Macías writes:
>>
>>> In the meantime, I'm submitting this patch with a fix for second-level
>>> French `smart quotes': the correct quotes should be “” (without spaces,
>>> as in Spanish or Greek) (please, some francophone correct me, if I'm
>>> wrong...).
>> Applied, thanks!
>
> I am not a francophone, I just have tried to look into sources I found
> during discussion on Greek quotes.
>
> https://en.wikipedia.org/wiki/Quotation_mark#French
> says that there are different styles of inner quotes.
>
> I am more worry that Unicode CLDR defines the same character for
> quotes.
Yes, this is also what the French national printing press ("Imprimerie
nationale"), which is quite authoritative in this matter, recommends.
Note that the Full recommendation of the Imprimerie nationale is to
repeat second-level quotation marks at the beginning and of each line
when the text spans over several lines, like this:
Then X reported : « This is what Y said : « Here is
« a quotation with a paragraph spaning over several
« lines, with each line starting with a quotation mark
« until the end of the quotation. »
(The unique » at the end is intentional, the rule is to not repeat.)
I don't have a strong opinion on this. I find the non-French
(e.g. canadian?) convention more sensible for digital documents (vs
printed ones): I expect repeating the quotation mark at the beginning
of each line is something software don't do. (Perhaps there is a
LaTeX package doing so, I've not checked.)
So I'd rather use this:
Then X reported : « This is what Y said : ”Here is
a quotation with a paragraph spaning over several
lines, with each line starting with a quotation mark
until the end of the quotation."»
WDYT?
--
Bastien
^ permalink raw reply [relevance 0%]
* Re: [patch] Fix inner smart quotes in French
2023-08-10 14:49 0% ` Bastien
@ 2023-08-10 21:50 10% ` Juan Manuel Macías
2023-08-13 9:20 6% ` Bastien Guerry
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-10 21:50 UTC (permalink / raw)
To: Bastien; +Cc: Max Nikulin, orgmode
Bastien writes:
> Yes, this is also what the French national printing press ("Imprimerie
> nationale"), which is quite authoritative in this matter, recommends.
>
> Note that the Full recommendation of the Imprimerie nationale is to
> repeat second-level quotation marks at the beginning and of each line
> when the text spans over several lines, like this:
>
> Then X reported : « This is what Y said : « Here is
> « a quotation with a paragraph spaning over several
> « lines, with each line starting with a quotation mark
> « until the end of the quotation. »
>
> (The unique » at the end is intentional, the rule is to not repeat.)
I've been looking at the babel-french documentation (LaTeX)
(http://mirrors.ctan.org/macros/latex/contrib/babel-contrib/french/frenchb.pdf),
which claims to be based on "Lexique des règles typographiques en usage
à l’Imprimerie Nationale, troisième édition (1994)"; p. 3 is about
quotation marks and the different options:
-----
with all engines: the inner quotation is surrounded by double quotes
(“texte”) unless option InnerGuillSingle=true, then a) the inner
quotation is printed as ‹ texte › and b) if the inner quotation spreads
over more than one paragraph, every paragraph included in the inner
quotation starts with a ‹ or a › or nothing, depending on option
EveryParGuill=open (default) or =close or =none.
with LuaTeX based engines, it is possible to add a French opening or
closing guillemet (« or ») at the beginning of every line of the inner
quotation using option EveryLineGuill=open or =close; note that with any
of these options, the inner quotation is surrounded by French guillemets
(« and ») regardless option InnerGuillSingle; the default is
EveryLineGuill=none so that \frquote{} behaves as with non-LuaTeX
engines.
-----
I have tried this example with quotes per line:
https://i.imgur.com/od4HwUs.png
In any case (apart from LaTeX), it is clear that I was wrong when I said
that the inner quotes that my patch 'corrects' were 'incorrect'. What I
don't know is why babel-french defaults to the « “inner” » style. Is it
the most used currently in France? If the « « inner » » style is more
canonical, I don't mind having my patch 'fix' reverted.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-10 10:39 10% ` Juan Manuel Macías
@ 2023-08-11 10:00 6% ` Ihor Radchenko
2023-08-11 18:52 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-11 10:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> ... In any case, the fact that the verse block can also be used to
> literally export line breaks and horizontal/vertical spaces is
> interesting. Something occurred to me that I don't know if it's a bit
> foolhardy: how about a LaTeX attribute ':literal t'? If used, it would
> not export to a verse environment (specialized in poetry) but to normal
> text, without environment, but with line breaks and horizontal and
> vertical spacing preserved... wdyt?
If one uses verse blocks to export to multiple backends, your suggestion
sounds reasonable. That way, export results will look closer across
different export backends.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-11 10:00 6% ` Ihor Radchenko
@ 2023-08-11 18:52 8% ` Juan Manuel Macías
2023-08-12 7:56 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-11 18:52 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> ... In any case, the fact that the verse block can also be used to
>> literally export line breaks and horizontal/vertical spaces is
>> interesting. Something occurred to me that I don't know if it's a bit
>> foolhardy: how about a LaTeX attribute ':literal t'? If used, it would
>> not export to a verse environment (specialized in poetry) but to normal
>> text, without environment, but with line breaks and horizontal and
>> vertical spacing preserved... wdyt?
>
> If one uses verse blocks to export to multiple backends, your suggestion
> sounds reasonable. That way, export results will look closer across
> different export backends.
How about this (pre-)patch? With the `:literal' attr., the content of the
block is exported "as is", with all manual formatting preserved.
I have made some modifications in the horizontal and vertical spaces (in
case :literal is used), because the em does not seem the correct length
to me. The em equals the font size in points, and, vertically, it would
not equal a blank line (line spacing is usually 120% of the em), so it's
safest to use \baselineskip. Thus, \vspace*{\baselineskip} is identical
to leaving an empty line. As for the horizontal space, the em is greater
than the normal space. The closest thing would be to use
\fontdimen2\font. So, if one puts 6 manual spaces (with the spacebar
key), it is exported as \hspace*{6\fontdimen2\font}
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-add-the-literal-attribute-to-verse-.patch --]
[-- Type: text/x-patch, Size: 3962 bytes --]
From baf9cc50313bb7df94e8173349db9c834f1ccf64 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 11 Aug 2023 19:57:49 +0200
Subject: [PATCH] lisp/ox-latex.el: add the `:literal' attribute to verse
block.
* (org-latex-verse-block): now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package. If the `':literal attribute is
used, the content is not exported within a `verse' environment, but as-is,
preserving horizontal spaces, line breaks, and blank lines.
---
lisp/ox-latex.el | 52 ++++++++++++++++++++++++++++++++++++------------
1 file changed, 39 insertions(+), 13 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..557ceee1b 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4116,32 +4116,58 @@ 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) "")))
+ (lit (org-export-read-attribute :attr_latex verse-block :literal))
+ (attr (if (not lit)
+ (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}" "")))
+ (vwidth (if (not lit)
+ (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")
+ ""))
+ (linreset (if (not lit)
+ (if lin "\n\\poemlines{0}" "")
+ "")))
(concat
(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 "%s\\begin{verse}%s\n%s\\end{verse}%s"
+ ;; into a normal space, calculated with `\fontdimen2\font'.
+ ;; One or more blank lines between lines are exported as a
+ ;; single blank line. If the `:literal' attribute is used,
+ ;; CONTENTS is exported as is, with no environment, preserving
+ ;; line breaks and vertical and horizontal spaces.
+ (format (if (not lit)
+ "%s\\begin{verse}%s\n%s\\end{verse}%s"
+ "%s%s\n%s%s")
vwidth
attr
(replace-regexp-in-string
- "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
+ "^[ \t]+" (lambda (m) (format "\\hspace*{%d\\fontdimen2\\font}" (length m)))
(replace-regexp-in-string
- (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")
- "\\vspace*{1em}"
+ (if (not lit)
+ (concat "\\("
+ (regexp-quote org-latex-line-break-safe)
+ "\n\\)"
+ "\\(^[ \t]*"
+ (regexp-quote org-latex-line-break-safe)
+ "\n"
+ "\\)+")
+ (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
+ (if (not lit)
+ (if lin "\\\\!\n\n" "\n\n")
+ "\\vspace*{\\baselineskip}")
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n"
(concat org-latex-line-break-safe "\n")
- contents nil t)
+ (if (not lit)
+ ;; Remove any blank lines before and after CONTENTS.
+ (concat (org-trim contents t) "\n")
+ contents)
+ nil t)
nil t)
nil t)
linreset)
--
2.41.0
^ permalink raw reply related [relevance 8%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-11 18:52 8% ` Juan Manuel Macías
@ 2023-08-12 7:56 5% ` Ihor Radchenko
2023-08-12 11:28 10% ` Juan Manuel Macías
2023-08-14 20:10 7% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2023-08-12 7:56 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> How about this (pre-)patch? With the `:literal' attr., the content of the
> block is exported "as is", with all manual formatting preserved.
Looks reasonable in general.
Of course, we will also need to document the new attribute.
> I have made some modifications in the horizontal and vertical spaces (in
> case :literal is used)...
Makes sense to me.
> + (vwidth (if (not lit)
> + (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")
> + ""))
Can just do (if (and versewidth (not lit)) (format ...) "")
> + (linreset (if (not lit)
> + (if lin "\n\\poemlines{0}" "")
> + "")))
(if (and lin (not lit)) ...)
> (concat
> (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 "%s\\begin{verse}%s\n%s\\end{verse}%s"
> + ;; into a normal space, calculated with `\fontdimen2\font'.
> + ;; One or more blank lines between lines are exported as a
> + ;; single blank line. If the `:literal' attribute is used,
> + ;; CONTENTS is exported as is, with no environment, preserving
> + ;; line breaks and vertical and horizontal spaces.
> + (format (if (not lit)
> + "%s\\begin{verse}%s\n%s\\end{verse}%s"
> + "%s%s\n%s%s")
In the case of lit vwidth and attr are always empty. So, you are
inserting an extra newline in front. Is it intentional?
> + (concat "\\("
> + (regexp-quote org-latex-line-break-safe)
> + "\n\\)"
> + "\\(^[ \t]*"
> + (regexp-quote org-latex-line-break-safe)
> + "\n"
> + "\\)+")
> + (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
May also use rx for better readability.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-12 7:56 5% ` Ihor Radchenko
@ 2023-08-12 11:28 10% ` Juan Manuel Macías
2023-08-13 8:06 6% ` Ihor Radchenko
2023-08-14 20:10 7% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-12 11:28 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>> + (vwidth (if (not lit)
>> + (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")
>> + ""))
>
> Can just do (if (and versewidth (not lit)) (format ...) "")
>
>> + (linreset (if (not lit)
>> + (if lin "\n\\poemlines{0}" "")
>> + "")))
>
> (if (and lin (not lit)) ...)
Thanks for the suggestions. Yes, it's simpler that way.
>> (concat
>> (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 "%s\\begin{verse}%s\n%s\\end{verse}%s"
>> + ;; into a normal space, calculated with `\fontdimen2\font'.
>> + ;; One or more blank lines between lines are exported as a
>> + ;; single blank line. If the `:literal' attribute is used,
>> + ;; CONTENTS is exported as is, with no environment, preserving
>> + ;; line breaks and vertical and horizontal spaces.
>> + (format (if (not lit)
>> + "%s\\begin{verse}%s\n%s\\end{verse}%s"
>> + "%s%s\n%s%s")
>
> In the case of lit vwidth and attr are always empty. So, you are
> inserting an extra newline in front. Is it intentional?
I used that procedure because an extra blank line before (in the LaTeX
code) it has no effect in LaTeX compilation. And in case the :literal
attribute is present, vertical spaces are achieved by explicit
\vspace*{}. One or more empty lines before it just marks the beginning
of a new paragraph.
Naturally, if :literal is used the rest of attributes are meaningless
because they are intended for the verse environment. They can even give
some error in the compilation. So I opted to disable them with the mere
presence of :literal, leaving them 'empty' (so as not to manipulate the
function further).
>> + (concat "\\("
>> + (regexp-quote org-latex-line-break-safe)
>> + "\n\\)"
>> + "\\(^[ \t]*"
>> + (regexp-quote org-latex-line-break-safe)
>> + "\n"
>> + "\\)+")
>> + (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
>
> May also use rx for better readability.
I remember that I tried rx a while ago and found it very useful and
comfortable, but then I haven't done anything with it. The fact is that
over time I have ended up getting used to suffering from the classic
regexp and it is hard for me to get out of there :-). Of course, with rx
it would be clearer but I would have to refresh my memory.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-12 11:28 10% ` Juan Manuel Macías
@ 2023-08-13 8:06 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-08-13 8:06 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>>> + (concat "\\("
>>> + (regexp-quote org-latex-line-break-safe)
>>> + "\n\\)"
>>> + "\\(^[ \t]*"
>>> + (regexp-quote org-latex-line-break-safe)
>>> + "\n"
>>> + "\\)+")
>>> + (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
>>
>> May also use rx for better readability.
>
> I remember that I tried rx a while ago and found it very useful and
> comfortable, but then I haven't done anything with it. The fact is that
> over time I have ended up getting used to suffering from the classic
> regexp and it is hard for me to get out of there :-). Of course, with rx
> it would be clearer but I would have to refresh my memory.
You can refer to [[info:elisp#Rx Constructs][elisp#Rx Constructs]]
I think your regexp in rx should look like
(rx-to-string `(seq (group ,org-latex-line-break-safe "\n")
(1+ (group line-start (0+ space) ,org-latex-line-break "\n"))))
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Fix inner smart quotes in French
2023-08-10 21:50 10% ` Juan Manuel Macías
@ 2023-08-13 9:20 6% ` Bastien Guerry
0 siblings, 0 replies; 200+ results
From: Bastien Guerry @ 2023-08-13 9:20 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, orgmode
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> In any case (apart from LaTeX), it is clear that I was wrong when I said
> that the inner quotes that my patch 'corrects' were 'incorrect'.
Indeed, and thanks for the discussion, interesting.
> What I
> don't know is why babel-french defaults to the « “inner” » style. Is it
> the most used currently in France? If the « « inner » » style is more
> canonical, I don't mind having my patch 'fix' reverted.
It's difficult to say what's more common but since we cannot expect
the « « inner » » style to be correctly implemented in, say, HTML, and
since, even in LaTeX, babel-french defaults to the « “inner” » style,
I suggest we stick to the « “inner” » style (this is a defcustom and
users can change it.)
Thanks!
--
Bastien Guerry
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-12 7:56 5% ` Ihor Radchenko
2023-08-12 11:28 10% ` Juan Manuel Macías
@ 2023-08-14 20:10 7% ` Juan Manuel Macías
2023-08-15 10:08 6% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-14 20:10 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
Ihor Radchenko writes:
> Looks reasonable in general. Of course, we will also need to document
> the new attribute.
Here is the modified patch (with your suggestions, including the `rx' code)
and the documentation of the new attribute.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-add-the-literal-attribute-to-verse-.patch --]
[-- Type: text/x-patch, Size: 5506 bytes --]
From 463e4a984b0ccc9bc1fdde699cb5cfed1ac59613 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 14 Aug 2023 21:48:58 +0200
Subject: [PATCH] lisp/ox-latex.el: add the `:literal' attribute to verse
block.
* (org-latex-verse-block): now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package. If the `:literal' attribute is
used, the content is not exported within a `verse' environment, but
as-is, preserving horizontal spaces, line breaks, and blank lines.
The rx code has been suggested by Ihor Radchenko, to improve
readability.
* doc/org-manual.org (Verse blocks in LaTeX export): the new feature
is documented.
---
doc/org-manual.org | 12 ++++++++++--
lisp/ox-latex.el | 43 ++++++++++++++++++++++++++++++-------------
2 files changed, 40 insertions(+), 15 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index e59efc417..b640bbc7c 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -14425,8 +14425,8 @@ The LaTeX export backend converts horizontal rules by the specified
#+cindex: verse blocks, in @LaTeX{} export
#+cindex: @samp{ATTR_LATEX}, keyword
-The LaTeX export backend accepts four attributes for verse blocks:
-=:lines=, =:center=, =:versewidth= and =:latexcode=. The three first
+The LaTeX export backend accepts five attributes for verse blocks:
+=:lines=, =:center=, =:versewidth=, =:latexcode= and =:literal=. The three first
require the external LaTeX package =verse.sty=, which is an extension
of the standard LaTeX environment.
@@ -14440,6 +14440,14 @@ of the standard LaTeX environment.
verse.
- =:latexcode= :: It accepts any arbitrary LaTeX code that can be
included within a LaTeX =verse= environment.
+- =:literal= :: With value t, the block is not exported to a =verse=
+ environment; instead, the content is exported as-is, preserving all
+ white lines as =\vspace{\baselineskip}=. Note that in the =verse=
+ environment, one or more blank lines between stanzas are exported as
+ a single blank line, and any blank lines before or after the content
+ are removed. If the =verse= package is loaded, the vertical spacing
+ between stanzas can be controlled by the length =\stanzaskip= (see
+ https://www.ctan.org/pkg/verse).
A complete example with Shakespeare's first sonnet:
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..fcf22f87d 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4116,32 +4116,49 @@ 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) "")))
+ (lit (org-export-read-attribute :attr_latex verse-block :literal))
+ (attr (if (not lit)
+ (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}" "")))
+ (vwidth (if (and versewidth (not lit)) (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
+ (linreset (if (and lin (not lit)) "\n\\poemlines{0}" "")))
(concat
(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 "%s\\begin{verse}%s\n%s\\end{verse}%s"
+ ;; into a normal space, calculated with `\fontdimen2\font'.
+ ;; One or more blank lines between lines are exported as a
+ ;; single blank line. If the `:literal' attribute is used,
+ ;; CONTENTS is exported as is, with no environment, preserving
+ ;; line breaks and vertical and horizontal spaces.
+ (format (if (not lit)
+ "%s\\begin{verse}%s\n%s\\end{verse}%s"
+ "%s%s\n%s%s")
vwidth
attr
(replace-regexp-in-string
- "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
+ "^[ \t]+" (lambda (m) (format "\\hspace*{%d\\fontdimen2\\font}" (length m)))
(replace-regexp-in-string
- (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")
- "\\vspace*{1em}"
+ (if (not lit)
+ (rx-to-string
+ `(seq (group ,org-latex-line-break-safe "\n")
+ (1+ (group line-start (0+ space) ,org-latex-line-break-safe "\n"))))
+ (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
+ (if (not lit)
+ (if lin "\\\\!\n\n" "\n\n")
+ "\\vspace*{\\baselineskip}")
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n"
(concat org-latex-line-break-safe "\n")
- contents nil t)
+ (if (not lit)
+ (concat (org-trim contents t) "\n")
+ contents)
+ nil t)
nil t)
nil t)
linreset)
--
2.41.0
^ permalink raw reply related [relevance 7%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-14 20:10 7% ` Juan Manuel Macías
@ 2023-08-15 10:08 6% ` Ihor Radchenko
2023-08-15 11:50 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-15 10:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> Looks reasonable in general. Of course, we will also need to document
>> the new attribute.
>
> Here is the modified patch (with your suggestions, including the `rx' code)
> and the documentation of the new attribute.
Thanks!
I tested the patch with
#+attr_latex: :literal t
#+begin_verse
This is just a test.
ASF.
#+end_verse
and then with
#+attr_latex: :literal t
#+begin_verse
This is just a test.
ASF.
#+end_verse
The output is not different, which it should be, AFAIU. Am I missing something?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-15 10:08 6% ` Ihor Radchenko
@ 2023-08-15 11:50 10% ` Juan Manuel Macías
2023-08-15 11:53 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-15 11:50 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Thanks!
> I tested the patch with
>
> #+attr_latex: :literal t
>
> #+begin_verse
>
> This is just a test.
> ASF.
>
> #+end_verse
>
>
> and then with
>
> #+attr_latex: :literal t
>
> #+begin_verse
>
> This is just a test.
>
> ASF.
>
> #+end_verse
>
> The output is not different, which it should be, AFAIU. Am I missing something?
I have tried your examples and I think both give the expected result.
Look at this screenshot:
https://i.imgur.com/ofl8Z9f.png
Note one important thing: the only horizontal spaces that are exported
"literally" (ie with \hspace...) are the ones at the beginning of the
line. This is the same as the old behavior, and works with both :literal
and the verse environment. Spaces between words are not exported. Well,
they are exported, but not as \hspace, so LaTeX resolves one or more
space to a single space. It could be an interesting feature that spaces
between words are also preserved, but none of the other backends do
that... Actually the :literal attribute has effect only on blank lines.
(Anyway, I think that without exporting the spaces between words, the
:literal attribute is a bit incomplete. But if those spaces are
exported, it would break compatibility with the other backends. The
horizontal space before the line makes sense for verses, because these
can often be indented arbitrarily in a poem. The other possibility is
that the :literal attribute also exports to a verse environment. In that
case, it would not break compatibility [the verse block in LaTeX would
just have two "modes": one more coherent with the syntax of the verse
environment and another one more similar to the behavior of the rest of
the backends and the "old" verse block behavior in LaTeX export]).
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-15 11:50 10% ` Juan Manuel Macías
@ 2023-08-15 11:53 6% ` Ihor Radchenko
2023-08-15 14:25 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-15 11:53 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> The output is not different, which it should be, AFAIU. Am I missing something?
>
> I have tried your examples and I think both give the expected result.
> Look at this screenshot:
>
> https://i.imgur.com/ofl8Z9f.png
Sure, but look at the pdf. The generated pdfs are not different for some
reason.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-15 11:53 6% ` Ihor Radchenko
@ 2023-08-15 14:25 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-15 14:25 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Sure, but look at the pdf. The generated pdfs are not different for some
> reason.
Ah, sorry. It was a foolish oversight of mine. The point is that a
\vspace after a line break in normal text has no effect. This does work:
lorem ipsum\\
\vspace*{10ex}\\
dolor
but it's a dirty workaround. In addition, there are more problems that I
had not noticed. If it is normal text, LaTeX indents the first line. A
\parindent=0 should be added, but that means complicating things
unnecessarily...
I think the best thing is to rethink the :literal attribute, as I
commented at the end of my other email:
- without :literal --> verse environment with a more "canonical" syntax.
- with :literal --> verse environment seen in the "old (org) style",
preserving the blank lines. In that context \vspace does work.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
Results 1001-1200 of ~1600 next (newer) | prev (older) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2020-09-08 5:39 idea for capture anywhere in x Maxim Nikulin
2020-09-08 22:40 ` Samuel Wales
2020-09-09 4:52 ` Maxim Nikulin
2020-09-10 14:23 ` Maxim Nikulin
2020-09-12 8:48 ` Nick Econopouly
2022-06-10 2:35 ` Samuel Wales
2022-10-09 14:47 ` Jean Louis
2022-10-09 16:40 ` Max Nikulin
2022-10-09 17:08 ` Jean Louis
2022-10-10 17:16 ` Max Nikulin
2022-10-10 22:06 ` Jean Louis
2022-10-11 9:11 9% ` Juan Manuel Macías
2022-10-12 1:09 5% ` Samuel Wales
2022-03-05 15:40 Filter for HTML footnotes? M. ‘quintus’ Gülker
2022-03-06 4:03 ` Juan Manuel Macías
2022-03-08 7:40 ` Filter for HTML (cite) footnotes? M. ‘quintus’ Gülker
2022-03-08 10:14 ` Juan Manuel Macías
2023-01-07 17:12 6% ` M. ‘quintus’ Gülker
2022-06-20 14:03 Org and Hyperbole Juan Manuel Macías
2022-06-20 15:26 ` Russell Adams
2022-06-20 23:37 ` Tim Cross
2022-09-27 13:06 ` Jean Louis
2022-09-27 15:08 0% ` Russell Adams
2022-06-24 1:45 Robert Weiner
2022-06-24 13:52 ` Juan Manuel Macías
2022-06-24 22:06 ` Robert Weiner
2022-06-25 14:32 ` Juan Manuel Macías
2022-10-08 20:34 6% ` Robert Weiner
2022-10-08 21:43 8% ` Juan Manuel Macías
2022-09-27 1:48 org exported pdf files Jude DaShiell
2022-09-27 2:48 ` Ihor Radchenko
2022-09-27 3:15 ` Jude DaShiell
2022-09-27 3:24 ` Ihor Radchenko
2022-09-27 4:31 ` Jude DaShiell
2022-09-27 4:58 ` Ihor Radchenko
2022-09-28 4:36 ` Jude DaShiell
2022-09-28 4:53 ` Timothy
2022-09-28 6:48 ` Jude DaShiell
2022-09-28 8:47 ` Tim Cross
2022-09-28 9:19 ` Timothy
2022-09-28 17:08 ` Tim Cross
2022-09-28 18:23 12% ` Juan Manuel Macías
2022-09-29 20:58 6% ` Tim Cross
2022-09-27 9:09 Create in Org a bilingual book with facing pages Juan Manuel Macías
2022-09-27 12:29 ` Ihor Radchenko
2022-09-27 16:50 11% ` Juan Manuel Macías
2022-09-28 3:15 5% ` Ihor Radchenko
2022-09-28 7:50 9% ` Explicit page breaks (was: Create in Org a bilingual book with facing pages) Juan Manuel Macías
2022-09-29 3:13 5% ` Ihor Radchenko
2022-09-29 5:29 7% ` Explicit page breaks Juan Manuel Macías
2022-09-29 6:21 4% ` Thomas S. Dye
2022-10-03 7:14 5% ` Ihor Radchenko
2022-10-04 20:24 8% ` Juan Manuel Macías
2022-10-05 7:59 5% ` Ihor Radchenko
2022-09-27 16:34 4% ` Create in Org a bilingual book with facing pages Hendursaga
2022-09-28 6:14 5% ` Juan Manuel Macías
2022-09-28 14:14 5% ` Hendursaga
2022-09-28 15:14 6% ` Juan Manuel Macías
2022-09-28 7:14 7% ` Christian Moe
2022-09-28 6:42 0% Pedro Andres Aranda Gutierrez
[not found] <E1ocmvz-0002iB-2M@fencepost.gnu.org>
2022-09-30 3:31 ` [HELP] Fwd: Org format as a new standard source format for GNU manuals Ihor Radchenko
2022-09-30 12:49 ` Max Nikulin
2022-10-01 3:30 ` Ihor Radchenko
2022-10-01 10:42 ` Max Nikulin
2022-10-01 11:01 ` Ihor Radchenko
2022-10-01 11:27 ` Max Nikulin
2022-10-02 4:59 ` Ihor Radchenko
2022-10-02 10:38 ` Fraga, Eric
2022-10-02 13:02 ` Ihor Radchenko
2022-10-02 13:47 13% ` Juan Manuel Macías
2022-10-03 4:23 5% ` Ihor Radchenko
2022-10-04 20:28 10% ` Juan Manuel Macías
2022-10-05 6:56 5% ` Rick Lupton
2022-10-05 9:49 8% A function to perform Org related searches in several places Juan Manuel Macías
2022-10-06 5:42 6% ` Ihor Radchenko
2022-10-06 13:20 Interest in an Org video meetup? Russell Adams
2022-10-06 20:09 10% ` Juan Manuel Macías
2022-10-06 21:06 6% ` Russell Adams
2022-10-07 1:43 6% ` Ihor Radchenko
2022-10-07 1:47 0% ` Russell Adams
2022-10-07 10:37 13% ` Juan Manuel Macías
2022-10-07 11:28 ` watch YT videos through in Emacs [Was: Interest in an Org video meetup?] Quiliro Ordóñez
2022-10-07 13:17 10% ` Juan Manuel Macías
2022-10-12 9:26 ` Ihor Radchenko
2022-10-12 10:22 9% ` Juan Manuel Macías
2022-10-12 10:52 6% ` Robert Weiner
2022-10-07 12:06 6% ` Interest in an Org video meetup? George Mauer
2022-10-09 15:12 0% ` Jean Louis
2022-10-08 14:29 7% [tip] Create and Insert a public Nextcloud/Owncloud link Juan Manuel Macías
2022-10-09 3:32 6% ` Max Nikulin
2022-10-09 12:21 11% ` Juan Manuel Macías
2022-10-09 20:15 idea for capture anywhere in x Ypo
2022-10-12 9:34 ` Ihor Radchenko
2022-10-12 10:43 ` Ypo
2022-10-12 14:22 8% ` Juan Manuel Macías
2022-10-10 15:19 10% Information about all LaTeX packages in an Org document Juan Manuel Macías
2022-10-14 18:16 Best android app Renato Pontefice
2022-10-14 18:37 ` Renato Pontefice
2022-10-14 18:52 10% ` Juan Manuel Macías
2022-10-15 15:14 12% Doubts about a function for my org-capture template Juan Manuel Macías
2022-10-16 8:32 6% ` Ihor Radchenko
2022-10-15 18:31 Best android app ypuntot
2022-10-15 23:01 6% ` Juan Manuel Macías
2022-10-16 0:57 6% ` Ypo
2022-10-17 18:01 5% ` Max Nikulin
2022-10-17 18:33 6% ` Juan Manuel Macías
2022-10-16 5:26 ` Max Nikulin
2022-10-16 7:32 ` Jean Louis
2022-10-16 9:22 ` Ihor Radchenko
2022-10-16 12:13 6% ` Juan Manuel Macías
2022-10-16 12:32 6% ` Ihor Radchenko
2022-10-16 13:14 6% ` Juan Manuel Macías
2022-10-16 15:02 6% ` Ihor Radchenko
2022-10-16 19:30 6% ` Juan Manuel Macías
2022-10-15 21:35 11% [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX Juan Manuel Macías
2022-10-16 3:24 5% ` Ihor Radchenko
2022-10-16 12:08 4% ` Juan Manuel Macías
2022-10-16 15:04 4% ` Max Nikulin
2022-10-16 16:33 4% ` Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
2022-10-17 8:54 6% ` Ihor Radchenko
2022-10-18 9:39 6% ` Verse block and separations Juan Manuel Macías
2022-10-17 14:48 7% ` Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Max Nikulin
2022-10-19 11:08 5% ` Max Nikulin
2022-10-19 11:24 6% ` Verse block and separations Juan Manuel Macías
2022-10-16 17:14 5% ` Line breaks and brackets in LaTeX export (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
2022-10-17 9:04 5% ` Ihor Radchenko
2022-10-17 11:30 7% ` Line breaks and brackets in LaTeX export Juan Manuel Macías
2022-10-17 11:47 5% ` Ihor Radchenko
2022-10-17 12:27 5% ` Juan Manuel Macías
2022-10-17 15:01 11% ` Juan Manuel Macías
2022-10-17 16:46 4% ` Max Nikulin
2022-10-17 18:04 7% ` Juan Manuel Macías
2022-10-18 4:41 6% ` Ihor Radchenko
2022-10-18 14:23 6% ` Juan Manuel Macías
2022-10-19 3:57 5% ` Ihor Radchenko
2022-10-19 5:11 0% ` Max Nikulin
2022-10-19 11:16 5% ` Juan Manuel Macías
2022-10-19 12:30 12% ` Juan Manuel Macías
2022-10-19 17:07 ` Max Nikulin
2022-10-20 16:55 4% ` Juan Manuel Macías
2022-10-21 3:34 5% ` Ihor Radchenko
2022-10-21 16:38 0% ` Max Nikulin
2022-10-21 19:32 9% ` Juan Manuel Macías
[not found] ` <ac290c60-3b54-5521-eb16-82e6611dc6e2@gmail.com>
2022-10-20 17:07 6% ` Juan Manuel Macías
2022-10-18 4:39 ` Ihor Radchenko
2022-10-19 17:12 ` Max Nikulin
2022-10-20 5:07 ` Ihor Radchenko
2022-10-20 17:15 ` Max Nikulin
2022-10-21 3:41 ` Ihor Radchenko
2022-10-21 16:32 ` Max Nikulin
2022-10-22 5:15 ` Ihor Radchenko
2022-10-22 12:26 10% ` Juan Manuel Macías
2022-10-22 15:55 ` Max Nikulin
2022-11-01 1:51 ` Ihor Radchenko
2022-11-01 16:07 ` Max Nikulin
2022-11-02 6:44 ` Ihor Radchenko
2022-11-02 6:46 ` Ihor Radchenko
2022-11-02 15:27 ` Max Nikulin
2022-11-03 6:15 ` Ihor Radchenko
2022-11-03 15:00 8% ` Juan Manuel Macías
2022-11-03 15:33 6% ` Max Nikulin
2022-11-03 15:48 6% ` Juan Manuel Macías
2022-11-04 4:23 ` Ihor Radchenko
2022-11-04 5:40 5% ` Max Nikulin
2022-10-23 15:16 9% [off-topic] E-readers and Org-Mode Juan Manuel Macías
2022-10-24 7:09 6% ` Fraga, Eric
2022-10-24 11:50 4% ` Juan Manuel Macías
2022-10-24 15:30 6% ` Fraga, Eric
2022-10-24 16:42 ` Jeffrey DeLeo
2022-10-24 17:16 ` Fraga, Eric
2022-10-24 18:34 5% ` Juan Manuel Macías
2022-10-25 7:57 6% ` Fraga, Eric
2022-10-25 12:55 6% ` Juan Manuel Macías
2022-10-25 13:59 6% ` Fraga, Eric
2022-10-26 13:31 6% ` L.C. Karssen
2022-10-29 9:03 12% ` Juan Manuel Macías
2022-10-25 14:37 5% ` Max Nikulin
2022-10-25 15:21 ` Fraga, Eric
2022-10-25 16:59 ` Ken Mankoff
2022-10-27 17:20 ` Max Nikulin
2022-10-27 17:53 8% ` Juan Manuel Macías
2022-10-28 4:40 6% ` Ihor Radchenko
2022-10-29 12:54 5% ` Max Nikulin
2022-10-31 12:18 8% ` Juan Manuel Macías
2022-10-24 7:12 Pedro Andres Aranda Gutierrez
2022-10-24 14:11 10% ` Juan Manuel Macías
2022-10-27 15:11 Error opening an .org file Renato Pontefice
2022-10-27 15:50 ` tomas
[not found] ` <624F24A1-CC82-45F5-8CB2-D9423A86E023@gmail.com>
[not found] ` <Y1qstDQckZLJR3eb@tuxteam.de>
2022-10-27 16:19 ` Renato Pontefice
2022-10-27 17:21 10% ` Juan Manuel Macías
2022-10-28 9:25 5% ` Tim Cross
2022-10-28 20:24 Org mode, Org Mode, Org-mode or Org-Mode? Marcin Borkowski
2022-10-28 20:55 10% ` Juan Manuel Macías
2022-10-29 12:08 Cannot find therefore at 972 character Renato Pontefice
2022-10-29 12:57 10% ` Juan Manuel Macías
2022-10-29 16:29 Position 972 Renato Pontefice
2022-10-29 17:46 ` tomas
2022-10-29 18:04 ` Renato Pontefice
2022-10-29 18:29 6% ` Juan Manuel Macías
2022-10-29 18:42 6% ` tomas
2022-10-29 18:16 7% ` Juan Manuel Macías
2022-10-29 18:44 7% ` tomas
2022-10-30 9:49 org-fstree.el overview over directories (but no comments are possible) Uwe Brauer
2022-10-30 12:52 9% ` Juan Manuel Macías
2022-10-30 13:10 1% ` Uwe Brauer
2022-10-30 13:56 9% ` Juan Manuel Macías
2022-10-30 14:01 ` Uwe Brauer
2022-10-30 15:40 9% ` Juan Manuel Macías
2022-10-30 16:42 0% ` Uwe Brauer
2022-10-30 17:16 ` Uwe Brauer
2022-10-30 18:17 9% ` Juan Manuel Macías
2022-10-30 18:48 ` Uwe Brauer
2022-10-30 19:04 9% ` Juan Manuel Macías
2022-10-30 19:21 0% ` Uwe Brauer
2022-10-30 19:26 ` [correction] (was: org-fstree.el overview over directories (but no comments are possible)) Uwe Brauer
2022-10-30 19:51 10% ` [correction] Juan Manuel Macías
2022-10-30 21:23 0% ` [correction] Uwe Brauer
2022-10-31 12:22 10% ` [correction] Juan Manuel Macías
2022-10-31 12:55 0% ` [correction] Uwe Brauer
2022-10-31 15:08 10% ` [correction] Juan Manuel Macías
2022-10-31 15:48 0% ` [correction] Uwe Brauer
2022-10-31 16:23 10% ` [correction] Juan Manuel Macías
2022-10-31 16:33 0% ` [correction] Uwe Brauer
2022-10-31 16:58 0% ` [correction] Uwe Brauer
2022-10-31 17:35 10% ` [correction] Juan Manuel Macías
2022-10-31 17:38 0% ` [correction] Uwe Brauer
2022-10-31 21:01 6% ` [correction] Juan Manuel Macías
2022-11-01 7:13 0% ` [correction] Uwe Brauer
2022-11-01 7:16 ` [correction] Uwe Brauer
2022-11-01 13:52 10% ` [correction] Juan Manuel Macías
2022-11-01 14:07 7% Docstrings and literate programming (good practices?) Juan Manuel Macías
2022-11-02 7:13 6% ` Ihor Radchenko
2022-11-02 7:53 0% ` Dr. Arne Babenhauserheide
2022-11-02 12:49 8% ` Juan Manuel Macías
2022-11-02 13:05 5% ` Ihor Radchenko
2022-11-02 15:20 8% ` Juan Manuel Macías
2022-11-03 7:38 5% ` Ihor Radchenko
2022-11-03 20:54 5% ` Rudolf Adamkovič
2022-11-04 3:03 0% ` Samuel Wales
2022-11-01 16:55 9% Line breaks and brackets in LaTeX export Juan Manuel Macías
2022-11-08 23:04 Can :packages and :headers arguments in latex SRC blocks be made affect EXPORT blocks of results? hugo
2022-11-09 17:30 8% ` Juan Manuel Macías
2022-11-10 6:11 [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)] Ihor Radchenko
2022-11-10 12:40 9% ` Juan Manuel Macías
2022-11-11 2:04 4% ` Ihor Radchenko
2022-11-11 15:08 8% ` Juan Manuel Macías
2022-11-13 4:09 3% ` Ihor Radchenko
2022-11-13 13:27 4% ` Juan Manuel Macías
2022-11-14 2:38 5% ` Ihor Radchenko
2022-11-14 22:25 8% ` Juan Manuel Macías
2022-11-15 2:46 5% ` Ihor Radchenko
2022-11-12 14:42 Help with a (query) replacement Ypo
2022-11-12 15:10 10% ` Juan Manuel Macías
2022-11-12 15:12 7% ` Ypo
2022-11-12 16:04 6% ` Juan Manuel Macías
2022-11-12 16:29 12% ` Juan Manuel Macías
2022-11-12 15:23 12% ` Juan Manuel Macías
2022-11-12 15:25 6% ` Ypo
2022-11-14 22:46 9% [PATCH] ox-latex: fix `org-latex-guess-babel-language' Juan Manuel Macías
2022-11-15 1:54 6% ` Ihor Radchenko
2022-11-17 14:48 10% ` Juan Manuel Macías
2022-11-18 8:31 6% ` Ihor Radchenko
2022-12-08 12:38 5% Macro: exporting roman numerals formatted as small-caps Carlos Martínez
2022-12-30 21:29 LaTeX tutorial (focused on what Org exports) ?? David Masterson
2022-12-31 1:18 ` Thomas S. Dye
2023-01-02 18:31 5% ` William Denton
2023-01-03 3:25 0% ` David Masterson
2023-01-06 19:46 OS advice Ypo
2023-01-07 22:22 7% ` Juan Manuel Macías
2023-01-07 22:28 7% ` Ypo
2023-02-18 10:18 [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated Ihor Radchenko
2023-03-05 11:12 5% ` Max Nikulin
2023-03-06 15:42 how to add special glyphs Rob Sargent
2023-03-07 15:54 6% ` Max Nikulin
2023-03-08 0:29 0% ` Rob Sargent
2023-06-20 4:42 How to tell `org-html-link' to create a link with some HTML class? Marcin Borkowski
2023-06-20 16:30 5% ` Max Nikulin
2023-08-04 7:25 12% [patch] Fix inner smart quotes in French Juan Manuel Macías
2023-08-04 11:09 6% ` Bastien
2023-08-10 14:10 0% ` Max Nikulin
2023-08-10 14:49 0% ` Bastien
2023-08-10 21:50 10% ` Juan Manuel Macías
2023-08-13 9:20 6% ` Bastien Guerry
2023-08-05 7:08 6% ` Ihor Radchenko
2023-08-05 10:51 12% ` Juan Manuel Macías
2023-08-05 13:19 6% ` Ihor Radchenko
2023-08-06 12:03 8% [patch] ox-latex.el: fix blank lines behavior in verse block Juan Manuel Macías
2023-08-07 11:40 6% ` Ihor Radchenko
2023-08-07 17:23 9% ` Juan Manuel Macías
2023-08-09 7:57 6% ` Ihor Radchenko
2023-08-09 8:41 12% ` Juan Manuel Macías
2023-08-10 9:27 5% ` Ihor Radchenko
2023-08-10 10:39 10% ` Juan Manuel Macías
2023-08-11 10:00 6% ` Ihor Radchenko
2023-08-11 18:52 8% ` Juan Manuel Macías
2023-08-12 7:56 5% ` Ihor Radchenko
2023-08-12 11:28 10% ` Juan Manuel Macías
2023-08-13 8:06 6% ` Ihor Radchenko
2023-08-14 20:10 7% ` Juan Manuel Macías
2023-08-15 10:08 6% ` Ihor Radchenko
2023-08-15 11:50 10% ` Juan Manuel Macías
2023-08-15 11:53 6% ` Ihor Radchenko
2023-08-15 14:25 11% ` 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).