emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* 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: 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: 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
  0 siblings, 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: 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, 1 reply; 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: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: 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: 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 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  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  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-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: [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: 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%]

* 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: [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%]

* 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 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 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 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: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 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 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 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 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-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: [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 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: [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: 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: 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 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 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 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 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 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 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: 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: 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: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: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: 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: [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: [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: 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: 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: [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: [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: 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-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: [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: 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-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-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-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 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 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  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-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%]

* [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: 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%]

* 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-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-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
       [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
  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
  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: 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  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 (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  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: 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-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: 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-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: 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 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-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 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: 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: 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: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: 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  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 (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: 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: 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%]

* 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%]

* 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%]

* 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%]

* 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: 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 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: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: [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: 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-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: 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: 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%]

* [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%]

* 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%]

* 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%]

* 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: 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: 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: 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: 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%]

* 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: 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%]

* 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: [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: 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: 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%]

* [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: 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%]

* 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: 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  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-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-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
  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: 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: [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%]

* 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: 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%]

* 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-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: 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: [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: [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: 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: 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: 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 (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: 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: 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: 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%]

* 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: 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%]

* Re: Create in Org a bilingual book with facing pages
  2022-09-27  9:09  8% Create in Org a bilingual book with facing pages Juan Manuel Macías
  2022-09-27 12:29  5% ` Ihor Radchenko
  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: 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: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 12:29  5% ` Ihor Radchenko
@ 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  9:09  8% Create in Org a bilingual book with facing pages Juan Manuel Macías
  2022-09-27 12:29  5% ` Ihor Radchenko
@ 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: Org and Hyperbole
  2022-09-27 13:06  0%     ` Jean Louis
@ 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: Org and Hyperbole
  @ 2022-09-27 13:06  0%     ` Jean Louis
  2022-09-27 15:08  0%       ` Russell Adams
  0 siblings, 1 reply; 200+ results
From: Jean Louis @ 2022-09-27 13:06 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-orgmode

* 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.

Let's say there is region marked, I use sometimes Hyperbole to search
Internet for marked term. That is not related and not comparable to
Org mode which is meant to handle markup in a text file.

Hyperbole is what it says, extravagant exaggeration. It is meta to
Org.

I have specific window setup with different buffers and I want to
remember it, then I use Hyperbole {C-h h w n a} to remember it.

One can understand it by running demo {C-h h d d}, it is not related
to Org mode, it is to be used in Emacs over anything, regardless of modes.


-- 
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%]

* Re: Create in Org a bilingual book with facing pages
  2022-09-27  9:09  8% Create in Org a bilingual book with facing pages Juan Manuel Macías
@ 2022-09-27 12:29  5% ` Ihor Radchenko
  2022-09-27 16:50 11%   ` Juan Manuel Macías
  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, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-09-27 12:29 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: 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. 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>

Thanks for sharing!

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?

> 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?

2. You had to use direct LaTeX for caption. Can we do something to make
   the #+caption keywords more useful?

-- 
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%]

* Create in Org a bilingual book with facing pages
@ 2022-09-27  9:09  8% Juan Manuel Macías
  2022-09-27 12:29  5% ` Ihor Radchenko
                   ` (2 more replies)
  0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-27  9:09 UTC (permalink / raw)
  To: orgmode

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

-- 
--
------------------------------------------------------
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com



^ permalink raw reply	[relevance 8%]

* Re: Extract toc from org file
  @ 2022-09-26 15:39 13%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-26 15:39 UTC (permalink / raw)
  To: reza; +Cc: orgmode

reza writes:

> Is there a way to extract a toc from an org file e.g:
>
>      #+INCLUDE: myfile.org :toc only
>
> I want to assemble the toc's from several files into one file and there
> seems to be no easy way to do this.

Maybe the org-make-toc package can help you with what you're looking for:

https://github.com/alphapapa/org-make-toc

You can choose a heading on every document to contain a TOC. And then link each heading via org-transclusion:

https://github.com/nobiot/org-transclusion

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: [Patch] Pre-/postpend arbitrary LaTeX code to a section
  2022-09-26  3:56  5%                 ` Ihor Radchenko
@ 2022-09-26  7:47 13%                   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-26  7:47 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> What I have in mind is to modify `org-export-read-attribute' directly.
> Then, we can call `org-export-read-attribute' in `org-export-data';
> resolve the refs in the template (re-use code from
> `org-babel-ref-resolve' and `org-babel-parse-multiple-vars'); do normal
> export and pass it to the template. Before running the normal export, we
> strip :export_template from the INFO to avoid issues with ox-html which
> puts every single attr into the generated html.

OK, it makes sense. I can try something on this idea, although I'm
afraid not in the short term. If someone else wants to do it I have no
problem.

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: [Patch] Pre-/postpend arbitrary LaTeX code to a section
  2022-09-25 12:06 10%               ` Juan Manuel Macías
@ 2022-09-26  3:56  5%                 ` Ihor Radchenko
  2022-09-26  7:47 13%                   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-09-26  3:56 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Going back to the earlier :ATTR_BACKEND: issue as a property for
> headings, I've been doing some testing and scribbled down a possible
> function[1] whose code is almost entirely stolen from
> org-export-read-attribute, with some modifications. Evaluated at the
> headline, it returns the value of the ATTR_BACKEND property as a plist.
> And then that plist could be easily manipulated on each backend to
> format export_template conveniently. For example:
>
> * headline
> :PROPERTIES:
> :ATTR_LaTeX: :export_template \begin{myenv}\n%s\n\end{myenv}
> :ATTR_LaTeX+: blah blah blah
> :END:
>
> ==> (:export_template "\\begin{myenv}\\n%s\\n\\end{myenv} blah blah blah")
>
> I don't know if that would be the way to go...

What I have in mind is to modify `org-export-read-attribute' directly.
Then, we can call `org-export-read-attribute' in `org-export-data';
resolve the refs in the template (re-use code from
`org-babel-ref-resolve' and `org-babel-parse-multiple-vars'); do normal
export and pass it to the template. Before running the normal export, we
strip :export_template from the INFO to avoid issues with ox-html which
puts every single attr into the generated html.

-- 
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: Dynamic keybindings in the manual
  @ 2022-09-25 17:52  3% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-25 17:52 UTC (permalink / raw)
  To: Timothy; +Cc: orgmode

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

Hi, Timothy,

Timothy writes:

> This prompted me to take a look at `orgcard.tex' and I was surprised to discover
> that it’s TeX TeX, not even LaTeX, and it has hard-coded keybindings.

Wow, it's in plainTeX... I've tried cleaning that document and removing
most of the code, as it's unnecessary. I've left just the sections in a
new LaTeX document, and redefined the \key command like so:

\newcommand\key[2]{%
  #1 \quad%
  \{\{\{kbd(#2)\}\}\}\par}

so that a line like this:

\key{rotate current subtree between states}{TAB}

produce in the PDF this, literally:

rotate current subtree between states {{{kbd(TAB)}}}

I don't know if this could help to copy the text from the PDF, create an
Org document and then manipulate those macros. In case this helps, I'm
attaching the new tex document here.

Best regards,

Juan Manuel

--
--
------------------------------------------------------
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com


[-- Attachment #2: orgcard-clean.tex --]
[-- Type: application/x-tex, Size: 14555 bytes --]

% -*- coding: utf-8 -*-

\documentclass{article}

\parindent=0em

\newcommand\key[2]{%
  #1 \quad %
  \{\{\{kbd(#2)\}\}\}\par}

\begin{document}

\section{Getting Started}
\key{To read the on-line documentation try}{M-x org-info}

\section{Visibility Cycling}

\key{rotate current subtree between states}{TAB}
\key{rotate entire buffer between states}{S-TAB}
\key{restore property-dependent startup visibility}{C-u C-u TAB}
\key{show the whole file, including drawers}{C-u C-u C-u TAB}
\key{reveal context around point}{C-c C-r}
\key{toggle indented view}{M-x org-indent-mode}

\section{Motion}

\key{next/previous heading}{C-c C-n/p}
\key{next/previous heading, same level}{C-c C-f/b}
\key{backward to higher level heading}{C-c C-u}
\key{jump to another place in document}{C-c C-j}
\key{previous/next plain list item}{S-UP/DOWN}

\section{Structure Editing}

\key{insert new heading/item at current level}{M-RET}
\key{insert new heading after subtree}{C-RET}
\key{insert new TODO entry/checkbox item}{M-S-RET}
\key{insert TODO entry/ckbx after subtree}{C-S-RET}
\key{turn (head)line into item, cycle item type}{C-c -}
\key{turn item/line into headline}{C-c *}
\key{promote/demote heading}{M-LEFT/RIGHT}
\key{promote/demote current subtree}{M-S-LEFT/RIGHT}
\key{move subtree/list item up/down}{M-UP/DOWN}
\key{move the line at point up/down}{M-S-UP/DOWN}
\key{sort subtree/region/plain-list}{C-c \^{}}
\key{clone a subtree}{C-c C-x c}
\key{copy visible parts of the region}{C-c C-x v}
\key{kill/copy subtree}{C-c C-x C-w/M-w}
\key{yank subtree}{C-c C-x C-y or C-y}
\key{narrow buffer to subtree / widen}{C-x n s/w}

\section{Capture - Refile - Archiving}
\key{capture a new item (C-u C-u = goto last)}{C-c c}
\key{refile subtree (C-u C-u = goto last)}{C-c C-w}
\key{archive subtree using the default command}{C-c C-x C-a}
\key{move subtree to archive file}{C-c C-x C-s}
\key{toggle ARCHIVE tag / to ARCHIVE sibling}{C-c C-x a/A}
\key{force cycling of an ARCHIVEd tree}{C-TAB}

\section{Filtering and Sparse Trees}

\key{construct a sparse tree by various criteria}{C-c /}
\key{view TODO's in sparse tree}{C-c / t/T}
\key{global TODO list in agenda mode}{C-c a t}

\section{Tables}

{\bf Creating a table}

%\key{insert a new Org-mode table}{M-x org-table-create}
\key{just start typing, e.g.}{|Name|Phone|Age RET |- TAB}
\key{convert region to table}{C-c |}
\key{... separator at least 3 spaces}{C-3 C-c |}

{\bf Commands available inside tables}

The following commands work when the cursor is {\it inside a table}.
Outside of tables, the same keys may have other functionality.

{\bf Re-aligning and field motion}

\key{re-align the table without moving the cursor}{C-c C-c}
\key{re-align the table, move to next field}{TAB}
\key{move to previous field}{S-TAB}
\key{re-align the table, move to next row}{RET}
\key{move to beginning/end of field}{M-a/e}

{\bf Row and column editing}

\key{move the current column left}{M-LEFT/RIGHT}
\key{kill the current column}{M-S-LEFT}
\key{insert new column to left of cursor position}{M-S-RIGHT}

\key{move the current row up/down}{M-UP/DOWN}
\key{kill the current row or horizontal line}{M-S-UP}
\key{insert new row above the current row}{M-S-DOWN}
\key{insert hline below (\texttt{C-u} : above) current row}{C-c -}
\key{insert hline and move to line below it}{C-c RET}
\key{sort lines in region}{C-c \^{}}

{\bf Regions}

\key{cut/copy/paste rectangular region}{C-c C-x C-w/M-w/C-y}
%\key{copy rectangular region}{C-c C-x M-w}
%\key{paste rectangular region}{C-c C-x C-y}

{\bf Miscellaneous}

\key{to limit column width to \texttt{N} characters, use}{...| <N> |...}
\key{edit the current field in a separate window}{C-c `}
\key{make current field fully visible}{C-u TAB}
\key{export as tab-separated file}{M-x org-table-export}
\key{import tab-separated file}{M-x org-table-import}
\key{sum numbers in current column/rectangle}{C-c +}

{\bf Tables created with the \texttt{table.el} package}

\key{insert a new \texttt{table.el} table}{C-c ~}
\key{recognize existing table.el table}{C-c C-c}
\key{convert table (Org-mode $\leftrightarrow$ table.el)}{C-c ~}

{\bf Spreadsheet}

Formulas typed in field are executed by \texttt{TAB},
\texttt{RET} and \texttt{C-c C-c}.  \texttt{=} introduces a column
formula, \texttt{:=} a field formula.

\key{Example: Add Col1 and Col2}{|=\$1+\$2      |}
\key{... with printf format specification}{|=\$1+\$2;\%.2f|}
\key{... with constants from constants.el}{|=\$1/\$c/\$cm |}
\key{sum from 2nd to 3rd hline}{|:=vsum(@II..@III)|}
\key{apply current column formula}{| = |}

\key{set and eval column formula}{C-c =}
\key{set and eval field formula}{C-u C-c =}
\key{re-apply all stored equations to current line}{C-c *}
\key{re-apply all stored equations to entire table}{C-u C-c *}
\key{iterate table to stability}{C-u C-u C-c *}
\key{rotate calculation mark through \# * ! \^ \_ \$}{C-\#}
\key{show line, column, formula reference}{C-c ?}
\key{toggle grid / debugger}{C-c \}/\{}

{\it Formula Editor}

\key{edit formulas in separate buffer}{C-c '}
\key{exit and install new formulas}{C-c C-c}
\key{exit, install, and apply new formulas}{C-u C-c C-c}
\key{abort}{C-c C-q}
\key{toggle reference style}{C-c C-r}
\key{pretty-print Lisp formula}{TAB}
\key{complete Lisp symbol}{M-TAB}
\key{shift reference point}{S-cursor}
\key{shift test line for column references}{M-up/down}
\key{scroll the window showing the table}{M-S-up/down}
\key{toggle table coordinate grid}{C-c \}}

\section{Links}

\key{globally store link to the current location}{C-c l}
\key{insert a link (TAB completes stored links)}{C-c C-l}
\key{insert file link with file name completion}{C-u C-c C-l}
\key{edit (also hidden part of) link at point}{C-c C-l}

\key{open file links in emacs}{C-c C-o}
\key{...force open in emacs/other window}{C-u C-c C-o}
\key{open link at point}{mouse-1/2}
\key{...force open in emacs/other window}{mouse-3}
\key{record a position in mark ring}{C-c \%}
\key{jump back to last followed link(s)}{C-c \&}
\key{find next link}{C-c C-x C-n}
\key{find previous link}{C-c C-x C-p}
\key{edit code snippet of file at point}{C-c '}
\key{toggle inline display of linked images}{C-c C-x C-v}

\section{Working with Code (Babel)}

\key{execute code block at point}{C-c C-c}
\key{open results of code block at point}{C-c C-o}
\key{check code block at point for errors}{C-c C-v c}
\key{insert a header argument with completion}{C-c C-v j}
\key{view expanded body of code block at point}{C-c C-v v}
\key{view information about code block at point}{C-c C-v I}
\key{go to named code block}{C-c C-v g}
\key{go to named result}{C-c C-v r}
\key{go to the head of the current code block}{C-c C-v u}
\key{go to the next code block}{C-c C-v n}
\key{go to the previous code block}{C-c C-v p}
\key{demarcate a code block}{C-c C-v d}
\key{execute next key sequence in code edit buffer}{C-c C-v x}
\key{execute all code blocks in current buffer}{C-c C-v b}
\key{execute all code blocks in current subtree}{C-c C-v s}
\key{tangle code blocks in current file}{C-c C-v t}
\key{tangle code blocks in supplied file}{C-c C-v f}
\key{ingest all code blocks in supplied file into the Library of Babel}{C-c C-v i}
\key{switch to the session of the current code block}{C-c C-v z}
\key{load the current code block into a session}{C-c C-v l}
\key{view sha1 hash of the current code block}{C-c C-v a}

\section{Completion and Template Insertion}

In-buffer completion completes TODO keywords at headline start, TeX
macros after ``{\tt \\}'', option keywords after ``{\tt \#-}'', TAGS
after  ``{\tt :}'', and dictionary words elsewhere.

\key{complete word at point}{M-TAB}
\key{structure template (insert or wrap region)}{C-c C-,}

\section{TODO Items and Checkboxes}

\key{rotate the state of the current item}{C-c C-t}
\key{select next/previous state}{\quad\quad S-LEFT/RIGHT}
\key{select next/previous set}{\quad\quad\quad C-S-LEFT/RIGHT}
\key{toggle ORDERED property}{C-c C-x o}

\key{view TODO items in a sparse tree}{C-c / t}
\key{view 3rd TODO keyword's sparse tree}{C-3 C-c / t}
\key{set the priority of the current item}{C-c , [ABC]}
\key{remove priority cookie from current item}{C-c , SPC}
\key{raise/lower priority of current item}{S-UP/DOWN}

\key{insert new checkbox item in plain list}{M-S-RET}
\key{toggle checkbox(es) in region/entry/at point}{C-c C-x C-b}
\key{toggle checkbox at point}{C-c C-c}
%\key{checkbox statistics cookies: insert {\tt [/]} or {\tt [\%]}}{}
\key{update checkbox statistics (\texttt{C-u} : whole file)}{C-c \#}

\section{Tags}

\key{set tags for current heading}{C-c C-q}
\key{realign tags in all headings}{C-u C-c C-q}
\key{create sparse tree with matching tags}{C-c}
\key{globally (agenda) match tags at cursor}{C-c C-o}

\section{Properties and Column View}

\key{set property/effort}{C-c C-x p/e}
\key{special commands in property lines}{C-c C-c}
\key{next/previous allowed value}{S-LEFT/RIGHT}
\key{turn on column view}{C-c C-x C-c}
\key{capture columns view in dynamic block}{C-c C-x x}

\key{quit column view}{q}
\key{show full value}{v}
\key{edit value}{e}
\key{next/previous allowed value}{n/p or S-LEFT/RIGHT}
\key{edit allowed values list}{a}
\key{make column wider/narrower}{> / <}
\key{move column left/right}{M-LEFT/RIGHT}
\key{add new column}{M-S-RIGHT}
\key{Delete current column}{M-S-LEFT}


\section{Timestamps}

\key{prompt for date and insert timestamp}{C-c .}
\key{like \texttt{C-c .} but insert date and time format}{C-u C-c .}
\key{like \texttt{C-c .} but make stamp inactive}{C-c !} % FIXME
\key{insert DEADLINE timestamp}{C-c C-d}
\key{insert SCHEDULED timestamp}{C-c C-s}
\key{create sparse tree with all deadlines due}{C-c / d}
\key{the time between 2 dates in a time range}{C-c C-y}
\key{change timestamp at cursor $\pm 1$ day}{\quad\quad\quad\quad S-RIGHT/LEFT}
\key{change year/month/day at cursor by $\pm 1$}{S-UP/DOWN}
\key{access the calendar for the current date}{C-c >}
\key{insert timestamp matching date in calendar}{C-c <}
\key{access agenda for current date}{C-c C-o}
\key{select date while prompted}{mouse-1/RET}
%\key{... select date in calendar}{mouse-1/RET}
%\key{... scroll calendar back/forward one month}{< / >}
%\key{... forward/backward one day}{S-LEFT/RIGHT}
%\key{... forward/backward one week}{S-UP/DOWN}
%\key{... forward/backward one month}{M-S-LEFT/RIGHT}
\key{toggle custom format display for dates/times}{C-c C-x C-t}

{\bf Clocking time}

\key{start clock on current item}{C-c C-x C-i}
\key{stop/cancel clock on current item}{C-c C-x C-o/x}
\key{display total subtree times}{C-c C-x C-d}
\key{remove displayed times}{C-c C-c}
\key{insert/update table with clock report}{C-c C-x C-x}

\section{Agenda Views}

\key{add/move current file to front of agenda}{C-c [}
\key{remove current file from your agenda}{C-c ]}
\key{cycle through agenda file list}{C-'}
\key{set/remove restriction lock}{C-c C-x </>}

\key{compile agenda for the current week}{C-c a a}
\key{compile global TODO list}{C-c a t}
\key{compile TODO list for specific keyword}{C-c a T}
\key{match tags, TODO kwds, properties}{C-c a m}
\key{match only in TODO entries}{C-c a M}
\key{find stuck projects}{C-c a \#}
\key{configure custom commands}{C-c a C}
%\key{configure stuck projects}{C-c a !}
\key{agenda for date at cursor}{C-c C-o}

{\bf Commands available in an agenda buffer}

{\bf View Org file}

\key{show original location of item}{SPC/mouse-3}
%\key{... also available with}{mouse-3}
\key{show and recenter window}{L}
\key{goto original location in other window}{TAB/mouse-2}
%\key{... also available with}{mouse-2}
\key{goto original location, delete other windows}{RET}
\key{show subtree in indirect buffer, ded.\ frame}{C-c C-x b}
\key{toggle follow-mode}{F}

{\bf Change display}

\key{delete other windows}{o}
\key{view mode dispatcher}{v}
\key{switch to day/week/month/year/def view}{d w vm vy vSP}
\key{toggle diary entries / time grid / habits}{D / G / K}
\key{toggle entry text / clock report}{E / R}
\key{toggle display of logbook entries}{l / v l/L/c}
\key{toggle inclusion of archived trees/files}{v a/A}
\key{refresh agenda buffer with any changes}{r / g}
\key{filter with respect to a tag}{/}
\key{save all org-mode buffers}{s}
\key{display next/previous day,week,...}{f / b}
\key{goto today / some date (prompt)}{. / j}

{\bf Remote editing}

\key{digit argument}{0-9}
\key{change state of current TODO item}{t}
\key{kill item and source}{C-k}
\key{archive default}{\$ / a}
\key{refile the subtree}{C-c C-w}
\key{set/show tags of current headline}{: / T}
\key{set effort property (prefix=nth)}{e}
\key{set / compute priority of current item}{, / P}
\key{raise/lower priority of current item}{S-UP/DOWN}
\key{run an attachment command}{C-c C-a}
\key{schedule/set deadline for this item}{C-c C-s/d}
\key{change timestamp one day earlier/later}{S-LEFT/RIGHT}
\key{change timestamp to today}{>}
\key{insert new entry into diary}{i}
\key{start/stop/cancel the clock on current item}{I / O / X}
\key{jump to running clock entry}{J}
\key{mark / unmark / execute bulk action}{m / u / B}

{\bf Misc}

\key{follow one or offer all links in current entry}{C-c C-o}

{\bf Calendar commands}

\key{find agenda cursor date in calendar}{c}
\key{compute agenda for calendar cursor date}{c}
\key{show phases of the moon}{M}
\key{show sunrise/sunset times}{S}
\key{show holidays}{H}
\key{convert date to other calendars}{C}

{\bf Quit and Exit}

\key{quit agenda, remove agenda buffer}{q}
\key{exit agenda, remove all agenda buffers}{x}

\section{LaTeX and cdlatex-mode}

\key{preview LaTeX fragment}{C-c C-x C-l}
\key{expand abbreviation (cdlatex-mode)}{TAB}
\key{insert/modify math symbol (cdlatex-mode)}{` / '}
\key{insert citation using RefTeX}{C-c C-x [}

\section{Exporting and Publishing}

Exporting creates files with extensions {\it .txt\/} and {\it .html\/}
in the current directory.  Publishing puts the resulting file into
some other place.

\key{export/publish dispatcher}{C-c C-e}

\key{toggle asynchronous export}{C-c C-e C-a}
\key{toggle body/visible only export}{C-c C-e C-b/v}
\key{toggle subtree export}{C-c C-e C-s}
\key{insert template of export options}{C-c C-e \#}

\key{toggle fixed width for entry or region}{C-c :}
\key{toggle pretty display of scripts, entities}{C-c C-x {\tt\char`\\}}

Lines starting with \texttt{\#} and subtrees starting with COMMENT are
never exported.

\key{toggle COMMENT keyword on entry}{C-c ;}

\section{Dynamic Blocks}

\key{update dynamic block at point}{C-c C-x C-u}
\key{update all dynamic blocks}{C-u C-c C-x C-u}

\end{document}





%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:

^ permalink raw reply	[relevance 3%]

* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
  2022-09-25  3:33  6%             ` Ihor Radchenko
@ 2022-09-25 12:06 10%               ` Juan Manuel Macías
  2022-09-26  3:56  5%                 ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-25 12:06 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

>>> #+ATTR_BACKEND: :export_template "can also work on non-headings"
>>> Paragraph.
>>
>> In this case I would not see it necessary, IMHO. For simple things (of
>> the begin/end style) there are the special blocks. And for more complex
>> pre- and/or post- code we have export blocks and export snippets. Since
>> there is no heading involved here, there would be no danger of the
>> pre-code leaving with the content of the previous header.
>
> I do not insist on this. I just see supporting this easier (it will work
> automatically) compared to explicitly limiting :export_template to
> headings/inlinetasks.
>
> Also, some people prefer to have such option (Pedro Andres Aranda
> Gutierrez in off-list reply to
> https://orgmode.org/list/87fsgmyyhw.fsf@localhost)

Well, it's evident that your idea of the export_template attribute is
very productive and can be consistently extended to more situations. One
scenario where I think it would be very useful is also in tables and
figures, but in this case to insert arbitrary code *inside* the table,
figure, etc. environments. This is something that gets asked on the list
from time to time and the solutions provided are usually a bit tricky.

Going back to the earlier :ATTR_BACKEND: issue as a property for
headings, I've been doing some testing and scribbled down a possible
function[1] whose code is almost entirely stolen from
org-export-read-attribute, with some modifications. Evaluated at the
headline, it returns the value of the ATTR_BACKEND property as a plist.
And then that plist could be easily manipulated on each backend to
format export_template conveniently. For example:

* headline
:PROPERTIES:
:ATTR_LaTeX: :export_template \begin{myenv}\n%s\n\end{myenv}
:ATTR_LaTeX+: blah blah blah
:END:

==> (:export_template "\\begin{myenv}\\n%s\\n\\end{myenv} blah blah blah")

I don't know if that would be the way to go...

Best regards,

Juan Manuel

[1]
(defun possible-function (attribute)
  "TODO"
  (let* ((prepare-value
	  (lambda (str)
	    (save-match-data
	      (cond ((member str '(nil "" "nil")) nil)
		    ((string-match "^\"\\(\"+\\)?\"$" str)
		     (or (match-string 1 str) ""))
		    (t str)))))
	 (attributes
	  (let ((value (org-entry-get nil attribute)))
	    (when value
	      (let ((s value) result)
		(while (string-match
			"\\(?:^\\|[ \t]+\\)\\(:[-a-zA-Z0-9_]+\\)\\([ \t]+\\|$\\)"
			s)
		  (let ((value (substring s 0 (match-beginning 0))))
		    (push (funcall prepare-value value) result))
		  (push (intern (match-string 1 s)) result)
		  (setq s (substring s (match-end 0))))
		;; Ignore any string before first property with `cdr'.
		(cdr (nreverse (cons (funcall prepare-value s) result))))))))
    attributes))


-- 
--
------------------------------------------------------
Juan Manuel Macías 

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com



^ permalink raw reply	[relevance 10%]

* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
  2022-09-24 14:50 11%           ` Juan Manuel Macías
@ 2022-09-25  3:33  6%             ` Ihor Radchenko
  2022-09-25 12:06 10%               ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-09-25  3:33 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

>> #+ATTR_BACKEND: :export_template "can also work on non-headings"
>> Paragraph.
>
> In this case I would not see it necessary, IMHO. For simple things (of
> the begin/end style) there are the special blocks. And for more complex
> pre- and/or post- code we have export blocks and export snippets. Since
> there is no heading involved here, there would be no danger of the
> pre-code leaving with the content of the previous header.

I do not insist on this. I just see supporting this easier (it will work
automatically) compared to explicitly limiting :export_template to
headings/inlinetasks.

Also, some people prefer to have such option (Pedro Andres Aranda
Gutierrez in off-list reply to
https://orgmode.org/list/87fsgmyyhw.fsf@localhost)

-- 
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 6%]

* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
  2022-09-22 14:08  5%         ` Ihor Radchenko
@ 2022-09-24 14:50 11%           ` Juan Manuel Macías
  2022-09-25  3:33  6%             ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-24 14:50 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Hi, Ihor, sorry for the late reply,

Ihor Radchenko writes:

> Having read the available replies in this thread, I am thinking of the
> following:
>
> 1. Instead of explicit prefix and suffix, we can unify extra text around
>    the exported Org element to a template:
>
> * headline
> :PROPERTIES:
> :ATTR_BACKEND: :export_template "\begin{myenv}\n%s\n\end{myenv}"
> :ATTR_BACKEND+: "The %%s instances are replaced by the exported element"
> :ATTR_BACKEND+: (concat "arbitrary sexp, the exported element is bound to: " *this*)
> :ATTR_BACKEND+: babel_block_name(exported=*this*)
> :ATTR_BACKEND+: "the property lines are concatenated with \" \" (space),"
> :ATTR_BACKEND+: "just like the usual approach in `org-export-read-attribute'"
> :END:

I really like this approach and I would buy it. On the one hand, if I
understand correctly, it's a universal solution that doesn't depend on a
particular backend (although, to be honest, I don't see much use for
this beyond LaTeX: maybe in HTML). And, on the other hand,
`:export_template' is an attribute that can be, as you say, very
versatile. With this, in my opinion, it would no longer be necessary to
define two 'pre' and 'post' attributes.

I imagine the value of ATTR_BACKEND (would quotes be necessary?) could
be easily converted to a plist, with code borrowed from
`org-export-read-attribute':

(:export_template "\\begin{myenv}\\n%s\\n\\end{myenv} ... etc. ...")

> #+ATTR_BACKEND: :export_template "can also work on non-headings"
> Paragraph.

In this case I would not see it necessary, IMHO. For simple things (of
the begin/end style) there are the special blocks. And for more complex
pre- and/or post- code we have export blocks and export snippets. Since
there is no heading involved here, there would be no danger of the
pre-code leaving with the content of the previous header.

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: [Patch] Pre-/postpend arbitrary LaTeX code to a section
  2022-09-21 14:43 10%       ` Juan Manuel Macías
@ 2022-09-22 14:08  5%         ` Ihor Radchenko
  2022-09-24 14:50 11%           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-09-22 14:08 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

>> I suggest to use more canonical attr_latex that explicitly limits the
>> export backend.
>
> I see. But in any case, something like `:prepend "section"' would be
> unnecessary (and even counterproductive) for what I'm proposing, but I'm
> afraid I didn't explain myself well in the first message. One of the
> benefits of approaching this issue with a few minor modifications to
> org-latex-headline is that the result is regardless of the section level
> at which the property is applied. We may want to prefix the section with
> a specific LaTeX code only for \section (or \paragraph or whatever) and
> we may want to introduce a more general LaTeX code, level-agnostic.
> Explicitly put "section", "subsection", etc, IMHO unnecessarily
> complicates things. But I also insist (as I said at the beginning) that
> I don't know if this use case can also be extended to other users.

Yeah. Extra matcher is probably too cumbersome.
Yet, I feel like conditional prefix/suffix may be useful in some
scenarios.

Having read the available replies in this thread, I am thinking of the
following:

1. Instead of explicit prefix and suffix, we can unify extra text around
   the exported Org element to a template:

* headline
:PROPERTIES:
:ATTR_BACKEND: :export_template "\begin{myenv}\n%s\n\end{myenv}"
:ATTR_BACKEND+: "The %%s instances are replaced by the exported element"
:ATTR_BACKEND+: (concat "arbitrary sexp, the exported element is bound to: " *this*)
:ATTR_BACKEND+: babel_block_name(exported=*this*)
:ATTR_BACKEND+: "the property lines are concatenated with \" \" (space),"
:ATTR_BACKEND+: "just like the usual approach in `org-export-read-attribute'"
:END:

#+ATTR_BACKEND: :export_template "can also work on non-headings"
Paragraph.

2. The generic Org export routine will remove the :export_template
   attributes prior to passing the element to backend-defined export
   transcoder, thus avoiding the problem Max raised wrt ox-html
   attributes.

3. Similar to :export_template, we can have
   :export_prefix/:export_suffix, but I feel that the template will be
   more flexible.

WDYT?

-- 
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: [Patch] Pre-/postpend arbitrary LaTeX code to a section
  @ 2022-09-21 14:51 13%         ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-21 14:51 UTC (permalink / raw)
  To: Daniel Fleischer; +Cc: Ihor Radchenko, orgmode

Daniel Fleischer writes:

> I don't understand the usecase, that's why I wasn't really following. If
> you write \vspace{10cm} before some headline, it's going to do the right
> thing even if it "belongs" to a previous headline.

Imagine, for example, that you have defined a LaTeX command that changes
the style of the section (or chapter, subsection, or whatever) below.
And you want to apply it before a certain section. If for any reason you
comment out the preceding section, or mark it as non-exportable, or even
delete it, the preceding command is no longer there when you export to
LaTeX. That would also happen if you move the section.

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: [Patch] Pre-/postpend arbitrary LaTeX code to a section
  2022-09-21  8:55  5%     ` Ihor Radchenko
  @ 2022-09-21 14:43 10%       ` Juan Manuel Macías
  2022-09-22 14:08  5%         ` Ihor Radchenko
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-21 14:43 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> It may produce unexpected results if "Section" heading is demoted all
> the way to paragraph.

If Section heading is demoted all the way to paragraph, I assume that
the expected will happen: that in the output to LaTeX a string will be
added before \paragraph and another string after the content of
\paragraph, which is perfectly consistent with the behavior of these two
properties. It is not that I intend to insist on a discussion; I just
don't quite understand what you mean. Note that these properties are for
LaTeX fine-tuning, and the user is expected to know what he/she wants
and where he/she wants it. If a user wants the arbitrary LaTeX code
before a certain header to be exported as a section (because, for
example, he/she has defined a command in LaTeX that changes the style of
the next \section), you would expect to put those properties in a
"\section" heading.

> Also, :presec/:postsec property names are
> confusing --- it is unclear if they are specific to LaTeX. (when about,
> say, Beamer)

Yes, I agree with that, and I had already commented on it in my previous
message, based on what Maxim had pointed out before, that the names I
had chosen were too imprecise. I like part of what you propose below:
`:attr_latex: :prepend'.

>>> However, I do agree that per-heading control over latex export is
>>> currently cumbersome.
>>>
>>> The canonical ox-latex approach to customize headline export is
>>> org-latex-classes variable. This variable defines (among other things)
>>> pre/post commands during headline export:
>>
>> Apologies in advance if I misunderstood what you're suggesting, but
>> isn't the "org-latex-classes" property supposed to affect the structure
>> of the entire document? What I'm proposing here is rather something
>> specific to particular headings (and its entire content), like the
>> ":ALT_TITLE:" property. If I understand correctly, what you are
>> suggesting is that org-latex-classes can have "local values" for
>> specific headings, if such headings are 'marked' with some property?
>
> Yes, org-latex-classes is controlling the entire document. What I am
> proposing (as an alternative) is subtree-level equivalent of
> org-latex-classes that is also close to org-latex-classes semantics.
>
> More concretely, I mean something like
>
> * Section
>   :PROPERTIES:
>   :attr_latex: :prepend "section" \setcounter{secnumdepth}{0}
>   :attr_latex+: :prepend "section" \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
>   :attr_latex+: :append "section" \setcounter{secnumdepth}{2}
>   :attr_latex+: :append "section" \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
>   :END:
>
> I suggest to use more canonical attr_latex that explicitly limits the
> export backend.

I see. But in any case, something like `:prepend "section"' would be
unnecessary (and even counterproductive) for what I'm proposing, but I'm
afraid I didn't explain myself well in the first message. One of the
benefits of approaching this issue with a few minor modifications to
org-latex-headline is that the result is regardless of the section level
at which the property is applied. We may want to prefix the section with
a specific LaTeX code only for \section (or \paragraph or whatever) and
we may want to introduce a more general LaTeX code, level-agnostic.
Explicitly put "section", "subsection", etc, IMHO unnecessarily
complicates things. But I also insist (as I said at the beginning) that
I don't know if this use case can also be extended to other users.

Best regards,

Juan Manuel 

-- 
--
------------------------------------------------------
Juan Manuel Macías 

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com




^ permalink raw reply	[relevance 10%]

* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
  2022-09-20 17:18 10%   ` Juan Manuel Macías
@ 2022-09-21  8:55  5%     ` Ihor Radchenko
    2022-09-21 14:43 10%       ` Juan Manuel Macías
  0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2022-09-21  8:55 UTC (permalink / raw)
  To: Juan Manuel Macías, Daniel Fleischer; +Cc: orgmode

Adding Daniel Fleischer (the ox-latex maintainer) to this exchange.

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Ihor Radchenko writes:
>
>> I do not like this idea.
>> Please remember that headlines may be exported as parts, sections,
>> subsections, list items, or paragraphs depending on the headline level.
>> Arbitrary pre/post commands may unexpectedly break things during export.
>
> I don't see why, if the user knows LaTeX and knows what he/she is doing.
> Sometimes it's just adding an "\addtocontents" just before the
> section/subsection,etc. The property that adds the string before and the
> property that adds the string after are understood to affect the entire
> heading at the current level and its contents, including lower levels.
> For example, if someone wants the current heading (and all its
> sublevels) not to be included in the TOC but to be included in the
> headers of the pages, it would suffice to (I keep here the original name
> of the properties that I proposed in the patch, but I think Maxim's
> proposed name is more accurate):
>
> -----------------------------------
>
> * Section
>   :PROPERTIES:
>   :presec:  \setcounter{secnumdepth}{0}
>   :presec+:  \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
>   :postsec: \setcounter{secnumdepth}{2}
>   :postsec+: \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
>   :END:
> Lorem ipsum dolor.

There is nothing wrong about this, but I feel that this kind of approach
is encouraging to shoot your own leg a bit too much. It will be better
if Org provides a semantics that is facilitating more safe approach.
More below.

> Which would pass to LaTeX as:
>
> \setcounter{secnumdepth}{0} \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
>
> \section{Section}
> Lorem ipsum dolor.
> \subsection{Subsection one}
> lorem
> \subsection{Subsection two}
> ipsum
>
> \setcounter{secnumdepth}{2} \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
> ----------------------------------
>
> (The above can even be simplified from LaTeX by defining a simple
> environment, but I've exemplified it like this to make it look better).
>
> In what situations might this return unexpected results?

It may produce unexpected results if "Section" heading is demoted all
the way to paragraph. Also, :presec/:postsec property names are
confusing --- it is unclear if they are specific to LaTeX. (when about,
say, Beamer)

>> However, I do agree that per-heading control over latex export is
>> currently cumbersome.
>>
>> The canonical ox-latex approach to customize headline export is
>> org-latex-classes variable. This variable defines (among other things)
>> pre/post commands during headline export:
>
> Apologies in advance if I misunderstood what you're suggesting, but
> isn't the "org-latex-classes" property supposed to affect the structure
> of the entire document? What I'm proposing here is rather something
> specific to particular headings (and its entire content), like the
> ":ALT_TITLE:" property. If I understand correctly, what you are
> suggesting is that org-latex-classes can have "local values" for
> specific headings, if such headings are 'marked' with some property?

Yes, org-latex-classes is controlling the entire document. What I am
proposing (as an alternative) is subtree-level equivalent of
org-latex-classes that is also close to org-latex-classes semantics.

More concretely, I mean something like

* Section
  :PROPERTIES:
  :attr_latex: :prepend "section" \setcounter{secnumdepth}{0}
  :attr_latex+: :prepend "section" \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
  :attr_latex+: :append "section" \setcounter{secnumdepth}{2}
  :attr_latex+: :append "section" \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
  :END:

I suggest to use more canonical attr_latex that explicitly limits the
export backend.

Further, it mentions a regexp limiting the applicable LaTeX environment
("section"). In other environments, the code will be omitted.

-- 
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: Re [Patch] Pre-/postpend arbitrary LaTeX code to a section
  @ 2022-09-20 19:35 12%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-20 19:35 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List

Ihor Radchenko writes:

>> Can it be extended to add properties to a
>> #BEGIN_example
>> #END_example
>> snippet?
>
> Didn't we conclude that wrapping blocks during LaTeX export should be
> done via special blocks? (This question has been raised multiple times,
> I am unsure if you are referring to the same discussion I have in mind).

Special blocks is usually the best solution for these cases. But
(without wishing to add more fuel to old discussions) I think it would
be nice to have as attr_latex a series of positions similar to the hooks
in the etoolbox LaTeX package:

\AtBeginEnvironment 
\AtEndEnvironment 
\BeforeBeginEnvironment
\AfterEndEnvironment

Something like :pre :post :precontent :postcontent.

In the case of blocks, I think this would simplify the documents a lot
if what you are looking for makes sense only in LaTeX export (special
blocks are exported to everything).

And in the case of floating objects such as tables or figures, it would
be really useful, since here you cannot resort to the use of special
blocks (*inside* those environments, I mean), and the workarounds that are
usually provided are still a bit tricky.

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: [Patch] Pre-/postpend arbitrary LaTeX code to a section
  2022-09-20 13:26  5% ` Ihor Radchenko
@ 2022-09-20 17:18 10%   ` Juan Manuel Macías
  2022-09-21  8:55  5%     ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-20 17:18 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> I do not like this idea.
> Please remember that headlines may be exported as parts, sections,
> subsections, list items, or paragraphs depending on the headline level.
> Arbitrary pre/post commands may unexpectedly break things during export.

I don't see why, if the user knows LaTeX and knows what he/she is doing.
Sometimes it's just adding an "\addtocontents" just before the
section/subsection,etc. The property that adds the string before and the
property that adds the string after are understood to affect the entire
heading at the current level and its contents, including lower levels.
For example, if someone wants the current heading (and all its
sublevels) not to be included in the TOC but to be included in the
headers of the pages, it would suffice to (I keep here the original name
of the properties that I proposed in the patch, but I think Maxim's
proposed name is more accurate):

-----------------------------------

* Section
  :PROPERTIES:
  :presec:  \setcounter{secnumdepth}{0}
  :presec+:  \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
  :postsec: \setcounter{secnumdepth}{2}
  :postsec+: \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
  :END:
Lorem ipsum dolor.

** Subsection one
lorem

** Subsection two
ipsum

Which would pass to LaTeX as:

\setcounter{secnumdepth}{0} \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}

\section{Section}
Lorem ipsum dolor.
\subsection{Subsection one}
lorem
\subsection{Subsection two}
ipsum

\setcounter{secnumdepth}{2} \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
----------------------------------

(The above can even be simplified from LaTeX by defining a simple
environment, but I've exemplified it like this to make it look better).

In what situations might this return unexpected results?

> However, I do agree that per-heading control over latex export is
> currently cumbersome.
>
> The canonical ox-latex approach to customize headline export is
> org-latex-classes variable. This variable defines (among other things)
> pre/post commands during headline export:

Apologies in advance if I misunderstood what you're suggesting, but
isn't the "org-latex-classes" property supposed to affect the structure
of the entire document? What I'm proposing here is rather something
specific to particular headings (and its entire content), like the
":ALT_TITLE:" property. If I understand correctly, what you are
suggesting is that org-latex-classes can have "local values" for
specific headings, if such headings are 'marked' with some property?

Best regards,

Juan Manuel 

------------------------------------------------------
Juan Manuel Macías 

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com



^ permalink raw reply	[relevance 10%]

* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
  2022-09-18 12:27  9% [Patch] Pre-/postpend arbitrary LaTeX code to a section Juan Manuel Macías
  2022-09-18 16:14  6% ` Max Nikulin
  2022-09-19 10:04  5% ` Fraga, Eric
@ 2022-09-20 13:26  5% ` Ihor Radchenko
  2022-09-20 17:18 10%   ` Juan Manuel Macías
  2 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-09-20 13:26 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> I don't know if the following scenario usually appears in the workflow
> of other Org users as well. Otherwise, I think this patch could be
> ignored.
>
> In my workflow I often need to pre- or postpend some LaTeX code
> immediately before or after a section. Consider the following example:
>
> ------------------
> * A section
>
> Lorem ipsum
>
> #+latex: \foo
>
> * Another section
>
> Lorem ipsum
> -----------------
>
> The \foo command affects the second section, but for Org it belongs to
> the content of the first section. If I comment this section out or mark
> it as non-exportable, then the LaTeX code has no effect. I think a
> simple solution could be to have the PRESEC AND POSTSEC properties to
> prepend or postpend arbitrary code to a section. These properties could be
> extended with PRESEC+ and POSTSEC+. An example of use:

I do not like this idea.
Please remember that headlines may be exported as parts, sections,
subsections, list items, or paragraphs depending on the headline level.
Arbitrary pre/post commands may unexpectedly break things during export.

However, I do agree that per-heading control over latex export is
currently cumbersome.

The canonical ox-latex approach to customize headline export is
org-latex-classes variable. This variable defines (among other things)
pre/post commands during headline export:

>> The sectioning structure of the class is given by the elements
>> following the header string.  For each sectioning level, a number
>> of strings is specified.  A %s formatter is mandatory in each
>> section string and will be replaced by the title of the section.
>> 
>> Instead of a cons cell (numbered . unnumbered), you can also
>> provide a list of 2 or 4 elements,
>> 
>>   (numbered-open numbered-close)
>> 
>> or
>> 
>>   (numbered-open numbered-close unnumbered-open unnumbered-close)
>> 
>> providing opening and closing strings for a LaTeX environment
>> that should represent the document section.  The opening clause
>> should have a %s to represent the section title.
>> 
>> Instead of a list of sectioning commands, you can also specify
>> a function name.  That function will be called with two
>> parameters, the (reduced) level of the headline, and a predicate
>> non-nil when the headline should be numbered.  It must return
>> a format string in which the section title will be added.

What about allowing to customize these open/close statements on
per-heading level during export? This will be more consistent with the
existing ox-latex structure.

-- 
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: [Patch] Pre-/postpend arbitrary LaTeX code to a section
  2022-09-18 12:27  9% [Patch] Pre-/postpend arbitrary LaTeX code to a section Juan Manuel Macías
  2022-09-18 16:14  6% ` Max Nikulin
@ 2022-09-19 10:04  5% ` Fraga, Eric
  2022-09-20 13:26  5% ` Ihor Radchenko
  2 siblings, 0 replies; 200+ results
From: Fraga, Eric @ 2022-09-19 10:04 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On Sunday, 18 Sep 2022 at 12:27, Juan Manuel Macías wrote:
> I don't know if the following scenario usually appears in the workflow
> of other Org users as well. Otherwise, I think this patch could be
> ignored.

I would find something like this useful as I often have commands such as
\newpage and \appendix preceding a headline, commands that are indeed
not really part of the previous element.

I've not tried your patch: I've been on holiday [1] and have come back
to 3000+ emails so I'll be some time...

eric

Footnotes:
[1]  definition: turn all Internet access off and have a break,
     preferably with good company, food, drink, and sunshine. 

-- 
: Eric S Fraga, with org release_9.5.4-768-g5bb699 in Emacs 29.0.50

^ permalink raw reply	[relevance 5%]

* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
  2022-09-18 12:27  9% [Patch] Pre-/postpend arbitrary LaTeX code to a section Juan Manuel Macías
@ 2022-09-18 16:14  6% ` Max Nikulin
  2022-09-19 10:04  5% ` Fraga, Eric
  2022-09-20 13:26  5% ` Ihor Radchenko
  2 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-09-18 16:14 UTC (permalink / raw)
  To: emacs-orgmode

On 18/09/2022 19:27, Juan Manuel Macías wrote:
> 
> * Section
>   :PROPERTIES:
>   :presec:  \begingroup\foo
>   :postsec: \endgroup
>   :END:

Juan Manuel, can it be implemented using a derived backend that calls 
the original variant of headline transcoder (`org-latex-headline') and 
adds pre/post code to the returned value? I have not tried to implement 
this idea, so perhaps I just have missed something obvious. Actually I 
wonder if the purpose of your patch is solely convenience or you faced a 
limitation with no reasonable workaround.

My only real objection is that the new keywords works for LaTeX only, 
but their names are rather generic. Moreover, Org's term is "headline", 
not "section". I would consider something like
- :headline_pre_latex: \begingroup\foo
- :headline_pre: :latex \begingroup\foo

By the way, are affiliated keywords a part of the following headline?

* Section One

#+attr_latex: :headline_pre \begingroup\foo
* Section Two



^ permalink raw reply	[relevance 6%]

* [Patch] Pre-/postpend arbitrary LaTeX code to a section
@ 2022-09-18 12:27  9% Juan Manuel Macías
  2022-09-18 16:14  6% ` Max Nikulin
                   ` (2 more replies)
  0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-18 12:27 UTC (permalink / raw)
  To: orgmode

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

Hi all,

I don't know if the following scenario usually appears in the workflow
of other Org users as well. Otherwise, I think this patch could be
ignored.

In my workflow I often need to pre- or postpend some LaTeX code
immediately before or after a section. Consider the following example:

------------------
* A section

Lorem ipsum

#+latex: \foo

* Another section

Lorem ipsum
-----------------

The \foo command affects the second section, but for Org it belongs to
the content of the first section. If I comment this section out or mark
it as non-exportable, then the LaTeX code has no effect. I think a
simple solution could be to have the PRESEC AND POSTSEC properties to
prepend or postpend arbitrary code to a section. These properties could be
extended with PRESEC+ and POSTSEC+. An example of use:

* Section
 :PROPERTIES:
 :presec:  \begingroup\foo
 :postsec: \endgroup
 :END:
...

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-Add-properties-for-arbitrary-LaTeX-.patch --]
[-- Type: text/x-patch, Size: 2844 bytes --]

From 56924d69a2090dfeedf4b35ca33e10a48cbc42b5 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 18 Sep 2022 13:56:05 +0200
Subject: [PATCH] lisp/ox-latex.el: Add properties for arbitrary LaTeX code.

* (org-latex-headline): The `PRESEC' and `POSTSEC' properties prepend
and postpend arbitrary LaTeX code to a section, respectively.
---
 lisp/ox-latex.el | 42 ++++++++++++++++++++++++++----------------
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 1eb70ab20..a8c9aecd2 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2322,22 +2322,32 @@ holding contextual information."
 			     (and (string-match-p "\\<headlines\\>" v)
 				  (string-match-p "\\<local\\>" v)
 				  (format "\\stopcontents[level-%d]" level)))))
-		    info t)))))
-	  (if (and opt-title
-		   (not (equal opt-title full-text))
-		   (string-match "\\`\\\\\\(.+?\\){" section-fmt))
-	      (format (replace-match "\\1[%s]" nil nil section-fmt 1)
-		      ;; Replace square brackets with parenthesis
-		      ;; since square brackets are not supported in
-		      ;; optional arguments.
-		      (replace-regexp-in-string
-		       "\\[" "(" (replace-regexp-in-string "\\]" ")" opt-title))
-		      full-text
-		      (concat headline-label pre-blanks contents))
-	    ;; Impossible to add an alternative heading.  Fallback to
-	    ;; regular sectioning format string.
-	    (format section-fmt full-text
-		    (concat headline-label pre-blanks contents))))))))
+		    info t))))
+              ;; `PRESEC' and `POSTSEC' properties for arbitrary LaTeX code.
+              (pre-sec (let ((beg (org-element-property :begin headline)))
+			 (goto-char beg)
+			 (org-entry-get nil "PRESEC")))
+	      (post-sec (let ((beg (org-element-property :begin headline)))
+			  (goto-char beg)
+			  (org-entry-get nil "POSTSEC"))))
+          (concat
+	   (when pre-sec (format "%s\n\n" pre-sec))
+	   (if (and opt-title
+		    (not (equal opt-title full-text))
+		    (string-match "\\`\\\\\\(.+?\\){" section-fmt))
+	       (format (replace-match "\\1[%s]" nil nil section-fmt 1)
+		       ;; Replace square brackets with parenthesis
+		       ;; since square brackets are not supported in
+		       ;; optional arguments.
+		       (replace-regexp-in-string
+		        "\\[" "(" (replace-regexp-in-string "\\]" ")" opt-title))
+		       full-text
+		       (concat headline-label pre-blanks contents))
+	     ;; Impossible to add an alternative heading.  Fallback to
+	     ;; regular sectioning format string.
+	     (format section-fmt full-text
+		     (concat headline-label pre-blanks contents)))
+           (when post-sec (format "%s\n\n" post-sec))))))))
 
 (defun org-latex-format-headline-default-function
     (todo _todo-type priority text tags _info)
-- 
2.37.3


^ permalink raw reply related	[relevance 9%]

* Re: error org export to pdf when latex letter class has been added to org-latex-classes
  2022-09-13 17:55 13% ` Juan Manuel Macías
@ 2022-09-13 19:59  5%   ` M. Pger
  2022-09-13 20:15 10%     ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: M. Pger @ 2022-09-13 19:59 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Hi,

Thank you for your answer.

> Are you including citations in your letter? 

No, that's also why it is puzzling. You should be able to reproduce the issue by creating a really minimalist init file including the following:
```
(with-eval-after-load 'ox-latex
  (add-to-list 'org-latex-classes '("letter" "\\documentclass{letter}"))
  )

(setq org-latex-pdf-process (list "latexmk -shell-escape -f -pdf %f"))
```

As mentioned in my previous mail, the error also appears when using `pdflatex` instead of `latexmk`.

Best,

M

------- Original Message -------
On Tuesday, September 13th, 2022 at 7:55 PM, Juan Manuel Macías <maciaschain@posteo.net> wrote:


> Hi,
> 
> M. Pger writes:
> 
> > (/usr/share/texlive/texmf-dist/tex/latex/natbib/natbib.sty
> > 
> > ! LaTeX Error: Environment thebibliography undefined.
> > 
> > See the LaTeX manual or LaTeX Companion for explanation.
> > Type H <return> for immediate help.
> > ...
> > 
> > l.1063 \renewenvironment{thebibliography}
> > [1]{%
> > ?
> > ! Emergency stop.
> > ...
> > 
> > l.1063 \renewenvironment{thebibliography}
> > [1]{%
> > ! ==> Fatal error occurred, no output PDF file produced!
> 
> 
> Are you including citations in your letter? Maybe this is related:
> https://latex.org/forum/viewtopic.php?f=4&t=3359
> 
> Best regards,
> 
> Juan Manuel
> 
> --
> --
> ------------------------------------------------------
> Juan Manuel Macías
> 
> https://juanmanuelmacias.com
> 
> https://lunotipia.juanmanuelmacias.com
> 
> https://gnutas.juanmanuelmacias.com


^ permalink raw reply	[relevance 5%]

* Re: error org export to pdf when latex letter class has been added to org-latex-classes
  2022-09-13 19:59  5%   ` M. Pger
@ 2022-09-13 20:15 10%     ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-13 20:15 UTC (permalink / raw)
  To: M. Pger; +Cc: orgmode

M. Pger writes:

> Thank you for your answer.
>
>> Are you including citations in your letter? 
>
> No, that's also why it is puzzling. You should be able to reproduce
> the issue by creating a really minimalist init file including the
> following:
>
> ```
> (with-eval-after-load 'ox-latex
>   (add-to-list 'org-latex-classes '("letter" "\\documentclass{letter}"))
>   )
>
> (setq org-latex-pdf-process (list "latexmk -shell-escape -f -pdf %f"))
> ```
>
> As mentioned in my previous mail, the error also appears when using `pdflatex` instead of `latexmk`.

Hmm, it's weird. With your configuration I cannot reproduce the problem.
Anyway, I have Org configured so that it doesn't load any package in the
preamble.

And if you directly compile the .tex file generated by org during
export, does it also give you an error? Could you please paste the
preamble of that tex file here, up to the \begin{document}?

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: error org export to pdf when latex letter class has been added to org-latex-classes
  @ 2022-09-13 17:55 13% ` Juan Manuel Macías
  2022-09-13 19:59  5%   ` M. Pger
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-13 17:55 UTC (permalink / raw)
  To: M. Pger; +Cc: orgmode

Hi,

M. Pger writes:

> (/usr/share/texlive/texmf-dist/tex/latex/natbib/natbib.sty
>
> ! LaTeX Error: Environment thebibliography undefined.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H <return>  for immediate help.
>  ...                                              
>                                                   
> l.1063 \renewenvironment{thebibliography}
>                                          [1]{%
> ? 
> ! Emergency stop.
>  ...                                              
>                                                   
> l.1063 \renewenvironment{thebibliography}
>                                          [1]{%
> !  ==> Fatal error occurred, no output PDF file produced!

Are you including citations in your letter? Maybe this is related:
https://latex.org/forum/viewtopic.php?f=4&t=3359

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: [off topic] List all non-latin characters in a buffer
  2022-08-19 14:50  1% ` Uwe Brauer
@ 2022-09-09 14:15  6%   ` Robert Pluim
  0 siblings, 0 replies; 200+ results
From: Robert Pluim @ 2022-09-09 14:15 UTC (permalink / raw)
  To: emacs-orgmode

>>>>> On Fri, 19 Aug 2022 16:50:54 +0200, Uwe Brauer <oub@mat.ucm.es> said:

    >>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
    Uwe> Hi Juan


    >> Sorry for the offtopic, but I thought this homemade function I wrote
    >> some time ago for my work might perhaps be useful to some Orgers. When
    >> executed in a buffer, the `list-non-latin-chars' function opens a window
    >> displaying a list of all the non (basic) Latin characters present in
    >> that document. Each item in the list contains the character, its Unicode
    >> canonical name, and its hexadecimal code. For example:

    Uwe> Very very nice,

    Uwe> Till now I used only a very simple search function

    Uwe> (defun my-search-no-ascii ()
    Uwe> "Simple function to search for no ASCII symbols in a file."
    Uwe>   (interactive)
    Uwe>   (skip-chars-forward "\001-\177"))

Equivalently you can do
 (skip-chars-forward "[[:ascii:]]")

(or use `re-search-forward' with the [:nonascii:] character class.)

Robert
-- 


^ permalink raw reply	[relevance 6%]

* Re: Agenda 'Org view' (org-projection?)
  @ 2022-09-06 14:21 13% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-06 14:21 UTC (permalink / raw)
  To: Eduardo Suarez; +Cc: orgmode

Hi, Eduardo:

Eduardo Suarez writes:

> Based on my previous mail "Manual Ordering and Dynamic Priority" I would like
> also to comment about this related idea.
>
> In Agenda, it is possible to generate different views. I wonder whether it
> would be possible to generate an "org mode" view. That is, a buffer in org-mode
> format with all the tasks from our agenda query (no really a sparse tree view).
> Then that file could be edited and reordered to create a planning. If the file
> could also sync with new queries that would be great. I think of that maybe as
> a package called 'org-projection' (project org into org).
>
> With such feature, I could have a general org file e.g. for a working project,
> and then a planning (projected) file in association with it. I would add the
> latter to the Agenda files.
>
> I can't do lisp development and have no idea if that makes sense, but I just
> wanted to share this idea with you.

I think this is not 100% related to what you're proposing, but if it
helps, I use the excellent org-super-agenda package a lot, which allows
you to sort and compose the agenda view according to many parameters:
tags, priorities, properties, etc:

https://github.com/alphapapa/org-super-agenda

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: Have all the tags of a heading, with a tag hierarchy
  2022-08-28 16:21 13% ` Juan Manuel Macías
@ 2022-08-28 16:34  5%   ` Cletip Cletip
  0 siblings, 0 replies; 200+ results
From: Cletip Cletip @ 2022-08-28 16:34 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

[-- Attachment #1: Type: text/plain, Size: 2264 bytes --]

Thank you for your answer!

I may not have been specific enough:
I want the tags also inherited with this "method"
https://orgmode.org/manual/Tag-Hierarchy.html.


So imagine this in your configuration file

(setq org-tag-alist '((:startgrouptag)
                      ("GTD")
                      (:grouptags)
                      ("Control")
                      (:Persp)
                      (:endgrouptag)
                      (:startgrouptag)
                      ( Control)
                      (:grouptags)
                      ("Context")
                      (:Task")
                      (:endgrouptag))


So, if I put the "Control" tag, I am also supposed to have the "GTD" tag,
because "Control" is a child of "GTD".

But, with the "org-get-tags" function, I don't have this famous "GTD" tag

Le dim. 28 août 2022 à 18:22, Juan Manuel Macías <maciaschain@posteo.net> a
écrit :

> Cletip Cletip writes:
>
> > After multiple searches on the internet, I did not find the answer to
> > my question (which is the subject of this mail): when calling the
> > "org-get-tags" function, only the tags put on the heading, and not the
> > inherited tags, are retrieved. How can I get the inherited tags as
> > well? Does such a function already exist? Did I miss an essential
> > variable?
>
> In my case, I do manage to get the iherited tags. Do you have
> `org-use-tag-inheritance' set to non-nil?
>
> According to the `org-get-tags' docstring:
>
> > According to ‘org-use-tag-inheritance’, tags may be inherited from
> > parent headlines, and from the whole document, through
> > ‘org-file-tags’. In this case, the returned list of tags contains tags
> > in this order: file tags, tags inherited from parent headlines, local
> > tags. If a tag appears multiple times, only the most local tag is
> > returned.
>
> and
>
> > However, when optional argument LOCAL is non-nil, only return tags
> > specified at the headline.
>
> 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: 3290 bytes --]

^ permalink raw reply	[relevance 5%]

* Re: Have all the tags of a heading, with a tag hierarchy
  @ 2022-08-28 16:21 13% ` Juan Manuel Macías
  2022-08-28 16:34  5%   ` Cletip Cletip
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-08-28 16:21 UTC (permalink / raw)
  To: Cletip Cletip; +Cc: orgmode

Cletip Cletip writes:

> After multiple searches on the internet, I did not find the answer to
> my question (which is the subject of this mail): when calling the
> "org-get-tags" function, only the tags put on the heading, and not the
> inherited tags, are retrieved. How can I get the inherited tags as
> well? Does such a function already exist? Did I miss an essential
> variable?

In my case, I do manage to get the iherited tags. Do you have
`org-use-tag-inheritance' set to non-nil?

According to the `org-get-tags' docstring:

> According to ‘org-use-tag-inheritance’, tags may be inherited from
> parent headlines, and from the whole document, through
> ‘org-file-tags’. In this case, the returned list of tags contains tags
> in this order: file tags, tags inherited from parent headlines, local
> tags. If a tag appears multiple times, only the most local tag is
> returned.

and

> However, when optional argument LOCAL is non-nil, only return tags
> specified at the headline.

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: Auto-checking dead links in the manual (was: http: links in the manual)
  2022-08-22  2:46  6%           ` Auto-checking dead links in the manual (was: http: links in the manual) Ihor Radchenko
@ 2022-08-22 15:29  0%             ` Max Nikulin
  0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-08-22 15:29 UTC (permalink / raw)
  To: emacs-orgmode

On 22/08/2022 09:46, Ihor Radchenko wrote:
> Juan Manuel Macías writes:
> 
>> Maybe, instead of repairing the links manually, we could think of some
>> code that would do this work periodically, and also check the health of
>> the links, running a url request on each link and returning a list of
>> broken links. I don't know if it is possible to do something like that
>> in Elisp, as I don't have much experience with web and link issues. I
>> think there are also external tools, like Selenium Web Driver, but my
>> experience with it is very limited (I use Selenium from time to time
>> when I want to take a screenshot of a web page).
> 
> This is a good idea.
> 
> Selenium is probably an overkill since we should better not link JS-only
> websites from the manual anyway. What we can do instead is a make target
> that will use something like wget.
> 
> Patches are welcome!

I hope that selenium is currently overkill, however more sites are 
starting to use anti-DDOS shields like cloudflare and HTTP client may be 
banned just because it does not fetch other resources like JS scripts.

I do not have a patch, just an idea: export backend that ignores 
everything besides link and either send requests from lisp code or 
generate file for another tool.

#+attr_linklint: ...

may be used to specify regexp that target page is expected to contain. 
There are some complications like e.g. "info:" links having special code 
to generate HTML with URL derived from original path. So it may be more 
robust to parse HTML document (without checking of linked document text).




^ permalink raw reply	[relevance 0%]

* Auto-checking dead links in the manual (was: http: links in the manual)
  2022-08-21  9:55  9%         ` Juan Manuel Macías
@ 2022-08-22  2:46  6%           ` Ihor Radchenko
  2022-08-22 15:29  0%             ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-08-22  2:46 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Max Nikulin, orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

>> Max Nikulin to emacs-orgmode. [PATCH] org-manual.org: Update links to
>> MathJax docs. Sun, 3 Oct 2021 23:17:46 +0700.
>> https://list.orgmode.org/sjcl3b$gsr$1@ciao.gmane.io
>>
>> In the particular case of docs.mathjax.org I am unsure if mild
>> preference of http: over https: is not a mistake in the server
>> configuration. I do not mind "https:" there, any variant is better
>> than the old broken link.
>
> Maybe, instead of repairing the links manually, we could think of some
> code that would do this work periodically, and also check the health of
> the links, running a url request on each link and returning a list of
> broken links. I don't know if it is possible to do something like that
> in Elisp, as I don't have much experience with web and link issues. I
> think there are also external tools, like Selenium Web Driver, but my
> experience with it is very limited (I use Selenium from time to time
> when I want to take a screenshot of a web page).

This is a good idea.

Selenium is probably an overkill since we should better not link JS-only
websites from the manual anyway. What we can do instead is a make target
that will use something like wget.

Patches are welcome!

-- 
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 6%]

* Re: http: links in the manual
  @ 2022-08-21  9:55  9%         ` Juan Manuel Macías
  2022-08-22  2:46  6%           ` Auto-checking dead links in the manual (was: http: links in the manual) Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-08-21  9:55 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

Max Nikulin writes:

> One may got no response trying to fix a link.
>
> Max Nikulin to emacs-orgmode. [PATCH] org-manual.org: Update links to
> MathJax docs. Sun, 3 Oct 2021 23:17:46 +0700.
> https://list.orgmode.org/sjcl3b$gsr$1@ciao.gmane.io
>
> In the particular case of docs.mathjax.org I am unsure if mild
> preference of http: over https: is not a mistake in the server
> configuration. I do not mind "https:" there, any variant is better
> than the old broken link.

Maybe, instead of repairing the links manually, we could think of some
code that would do this work periodically, and also check the health of
the links, running a url request on each link and returning a list of
broken links. I don't know if it is possible to do something like that
in Elisp, as I don't have much experience with web and link issues. I
think there are also external tools, like Selenium Web Driver, but my
experience with it is very limited (I use Selenium from time to time
when I want to take a screenshot of a web page).

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: [PATCH] Documentation and NEWS for ` org-latex-language-alist'
  2022-08-16 14:16  8%   ` Juan Manuel Macías
  2022-08-18 15:39  6%     ` Max Nikulin
@ 2022-08-20  5:51  5%     ` Ihor Radchenko
    1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-08-20  5:51 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, Maxim Nikulin

Juan Manuel Macías <maciaschain@posteo.net> writes:

> I am attaching a new version of the patch.

Thanks!
Applied onto main via 243ded74b adding one sentence to the =LANGUAGE=
keyword description and changing the ctan links to https.

I have added a short description of what LANGUAGE keyword value is:
"Language code of the primary document language."

> Addendum: Just as I was going to send this email, I saw the other email
> from Maxim in this thread, who says:
>
>> Firefox may block downloading of a file through unencrypted http:
>> protocol if a link is opened from a https: page (HTML version of the
>> Org manual served from orgmode.org this case). The problem with CTAN
>> mirrors is that not all hosts have TLS certificates including their
>> CTAN names.
>
> I can't figure out how to link to the babel documentation in a way other
> than a link to CTAN. If this might be an inconvenience (due to https
> issues), perhaps we could simply put in the documentation something like
> 'see the Babel docs', or referencing the command 'texdoc -M
> babel', which opens the locally installed babel documentation. The
> problem is that not all GNU/Linux distributions include the
> documentation in their versions of TeX live. For example, Arch Linux
> does not include documentation in the official repos and must be
> installed separately via an AUR package.

I went with https. It does open at least in some cases. The problem with
CTAN certificates is not our problem. Users may still search the
relevant documents if the link is dead.

Note that we still have a number of http links in the manual. One may
want to fix them.

-- 
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: [off topic] List all non-latin characters in a buffer
  2022-08-16 15:19  9% [off topic] List all non-latin characters in a buffer Juan Manuel Macías
@ 2022-08-19 14:50  1% ` Uwe Brauer
  2022-09-09 14:15  6%   ` Robert Pluim
  0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-08-19 14:50 UTC (permalink / raw)
  To: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
Hi Juan


> Sorry for the offtopic, but I thought this homemade function I wrote
> some time ago for my work might perhaps be useful to some Orgers. When
> executed in a buffer, the `list-non-latin-chars' function opens a window
> displaying a list of all the non (basic) Latin characters present in
> that document. Each item in the list contains the character, its Unicode
> canonical name, and its hexadecimal code. For example:

Very very nice,

Till now I used only a very simple search function

(defun my-search-no-ascii ()
"Simple function to search for no ASCII symbols in a file."
  (interactive)
  (skip-chars-forward "\001-\177"))

That is so much better!

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

^ permalink raw reply	[relevance 1%]

* Re: [PATCH] Documentation and NEWS for ` org-latex-language-alist'
  2022-08-16 14:16  8%   ` Juan Manuel Macías
@ 2022-08-18 15:39  6%     ` Max Nikulin
  2022-08-20  5:51  5%     ` Ihor Radchenko
  1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2022-08-18 15:39 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On 16/08/2022 21:16, Juan Manuel Macías wrote:
> 
>> Firefox may block downloading of a file through unencrypted http:
>> protocol if a link is opened from a https: page (HTML version of the
>> Org manual served from orgmode.org this case). The problem with CTAN
>> mirrors is that not all hosts have TLS certificates including their
>> CTAN names.
> 
> I can't figure out how to link to the babel documentation in a way other
> than a link to CTAN. If this might be an inconvenience (due to https
> issues), perhaps we could simply put in the documentation something like
> 'see the Babel docs', or referencing the command 'texdoc -M
> babel', which opens the locally installed babel documentation. The
> problem is that not all GNU/Linux distributions include the
> documentation in their versions of TeX live. For example, Arch Linux
> does not include documentation in the official repos and must be
> installed separately via an AUR package.

I would suggest https (TLS) link and title of the document. I believe 
that is should be a requirement for "official" CTAN mirrors to have 
valid TLS certificate.

P.S. Why there is no ol-texdoc.el?


^ permalink raw reply	[relevance 6%]

* [off topic] List all non-latin characters in a buffer
@ 2022-08-16 15:19  9% Juan Manuel Macías
  2022-08-19 14:50  1% ` Uwe Brauer
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-08-16 15:19 UTC (permalink / raw)
  To: orgmode

Sorry for the offtopic, but I thought this homemade function I wrote
some time ago for my work might perhaps be useful to some Orgers. When
executed in a buffer, the `list-non-latin-chars' function opens a window
displaying a list of all the non (basic) Latin characters present in
that document. Each item in the list contains the character, its Unicode
canonical name, and its hexadecimal code. For example:

殿  CJK IDEOGRAPH-6BBF  #6bbf

Also, each item is a button (created with button.el). If the button
is activated, there are currently two options: a: execute occur on that
character in the document; b : execute describe-char on that character.

By default, the characters displayed in the list correspond to any
Unicode block other than basic-latin. Which means that the zero width
space character is included, a very famous character in this mailing
list :-)

And here is the code (lexical binding is required). Of course, feedback
welcome.

Best regards,

Juan Manuel

#+begin_src emacs-lisp
  (setq ext-chars-actions-list '((?a "Occur"
				      (lambda (buf char)
					(interactive)
					(with-current-buffer buf
					  (occur char))))
				  (?b "Describe char"
				      (lambda (buf char)
					(interactive)
					(with-current-buffer buf
					  (save-excursion
					    (goto-char (point-min))
					    (when (re-search-forward char nil t)
					      (describe-char (- (point) 1)))))))))

  (defun ext-chars-choose-action (buf char)
    (let ((opt (read-char-choice (concat "Escoger acción >>\n\n"
					 (mapconcat (lambda (item)
						      (format "%c: %s"
							      (car item) (nth 1 item)))
						    ext-chars-actions-list " --- "))
				 (mapcar #'car ext-chars-actions-list))))
      (apply (nth 2 (assoc opt ext-chars-actions-list))
	     (list buf char))))

  (defvar ext-chars-list nil)

  (defun list-non-latin-chars ()
    (interactive)
    (setq ext-chars-list nil)
    (let ((buf (buffer-name)))
      (save-excursion
	(goto-char (point-min))
	(while
	    (re-search-forward "\\([^\u0000-\u007F]\\)" nil t)
	  (add-to-list 'ext-chars-list (format "%s" (match-string 1))))
	(setq ext-chars-list-final
	      (mapcar (lambda (char)
			(let
			    ((char-name (get-char-code-property (string-to-char char) 'name))
			     ;; convert to hexadecimal
			     (char-code (format "#%x" (string-to-char char))))
			  (setq char (format  "%s\s\s%s\s\s%s" char char-name char-code))))
		      ext-chars-list))
	(let ((temp-buf (format "*non latin chars in %s*" buf)))
	  (when (get-buffer temp-buf)
	    (kill-buffer temp-buf))
	  (get-buffer-create temp-buf)
	  (set-buffer temp-buf)
          ;; necessary for Arabic, Hebrew, etc.
	  (setq bidi-display-reordering nil)
          ;; insert buttons list
	  (mapc (lambda (el)
		  (let ((char (when (string-match "^\\(.\\)\s" el)
				(match-string 1 el))))
		    (insert-button (format "%s" el)
				   'action (lambda (x) 
					     (interactive) 
					     (ext-chars-choose-action buf char)))
		    (insert "\n\n")))
		ext-chars-list-final)
	  (pop-to-buffer temp-buf)
	  (goto-char (point-min))
	  (view-mode)))))
#+end_src

-- 
--
------------------------------------------------------
Juan Manuel Macías 

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com




^ permalink raw reply	[relevance 9%]

* Re: [PATCH] Documentation and NEWS for ` org-latex-language-alist'
  2022-08-09 11:43  5% ` Ihor Radchenko
@ 2022-08-16 14:16  8%   ` Juan Manuel Macías
  2022-08-18 15:39  6%     ` Max Nikulin
  2022-08-20  5:51  5%     ` Ihor Radchenko
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-16 14:16 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode, Maxim Nikulin

[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]

Hi, Ihor. Sorry for my late reply. These last few days have been a bit
complicated for me due to work issues.

Ihor Radchenko writes:

> I feel like we should first describe what #+LANGUAGE keyword does and
> go into the gory details of LaTeX language support a bit later.
>
> Basically, I am asking you to reshuffle paragraphs a bit possibly moving
> some parts to more relevant 13.10.3 LaTeX header and sectioning
> structure. People have no idea about #+LATEX_HEADER when reading 13.10.2
> LaTeX specific export settings (coming before the 13.10.3).

I am attaching a new version of the patch.

Addendum: Just as I was going to send this email, I saw the other email
from Maxim in this thread, who says:

> Firefox may block downloading of a file through unencrypted http:
> protocol if a link is opened from a https: page (HTML version of the
> Org manual served from orgmode.org this case). The problem with CTAN
> mirrors is that not all hosts have TLS certificates including their
> CTAN names.

I can't figure out how to link to the babel documentation in a way other
than a link to CTAN. If this might be an inconvenience (due to https
issues), perhaps we could simply put in the documentation something like
'see the Babel docs', or referencing the command 'texdoc -M
babel', which opens the locally installed babel documentation. The
problem is that not all GNU/Linux distributions include the
documentation in their versions of TeX live. For example, Arch Linux
does not include documentation in the official repos and must be
installed separately via an AUR package.

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-doc-org-manual.org-documentation-for-org-latex-langu.patch --]
[-- Type: text/x-patch, Size: 4628 bytes --]

From 46192df70cd00e2eca2e8e059e9d39723b9d32d8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 16 Aug 2022 15:41:22 +0200
Subject: [PATCH] doc/org-manual.org: documentation for
 `org-latex-language-alist'

* etc/ORG-NEWS: update the news with the new variable.
---
 doc/org-manual.org | 58 ++++++++++++++++++++++++++++++++++++++++++++--
 etc/ORG-NEWS       | 13 +++++++++++
 2 files changed, 69 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 466718e6e..8973f08ce 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13370,15 +13370,21 @@ general options (see [[*Export Settings]]).
 - =LANGUAGE= ::
   #+cindex: @samp{LANGUAGE}, keyword
   #+vindex: org-latex-packages-alist
+  #+vindex: org-latex-language-alist
+  
+  The list of languages supported by Org is stored in the variable
+  ~org-latex-language-alist~.
+
   In order to be effective, the =babel= or =polyglossia=
   packages---according to the LaTeX compiler used---must be loaded
   with the appropriate language as argument.  This can be accomplished
   by modifying the ~org-latex-packages-alist~ variable, e.g., with the
-  following snippet:
+  following snippet (note that =polyglossia= does not work with
+  pdfLaTeX):
 
   #+begin_src emacs-lisp
   (add-to-list 'org-latex-packages-alist
-               '("AUTO" "babel" t ("pdflatex")))
+               '("AUTO" "babel" t ("pdflatex" "xelatex" "lualatex")))
   (add-to-list 'org-latex-packages-alist
                '("AUTO" "polyglossia" t ("xelatex" "lualatex")))
   #+end_src
@@ -13508,6 +13514,54 @@ A sample Org file with the above headers:
   some more text
 #+end_example
 
+#+cindex: @samp{LANGUAGE}, keyword
+#+vindex: org-export-default-language
+LaTeX packages =babel= or =polyglossia= can also be loaded in a
+document.  The "AUTO" string will be replaced in both cases by the
+appropiate value for the =LANGUAGE= keyword, if present in the
+document, or by the value of ~org-export-default-language~.  Let's see
+some examples in one or another case.
+
+=Babel= accepts the classic syntax and (in addition) the new syntax
+with the =\babelprovide= command to load the languages using the new
+=INI= files procedure.  Keep in mind that there are a number of
+languages that are only served in babel using =INI= files, so they
+cannot be declared using the classic syntax, but only using the
+=\babelprovide= command (see
+http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf).
+Valid usage examples could be:
+
+#+begin_example
+,#+LATEX_HEADER: \usepackage[french,italian,AUTO]{babel}
+#+end_example
+
+where "AUTO" is the main language.  But it can also be loaded using
+the =\babelprovide= command:
+
+#+begin_example
+,#+LATEX_HEADER: \usepackage[french,italian]{babel}
+,#+LATEX_HEADER: \babelprovide[import, main]{AUTO}
+#+end_example
+
+=Polyglossia=, for this procedure to be effective, must be loaded
+using the same =babel= classic syntax (but note that /this is not/
+the actual polyglossia syntax).  For example, suppose a document
+declares Polytonic Greek as the primary language, and French as the
+secondary language.  In this case, it would be expressed as:
+
+#+begin_example
+,#+LANGUAGE: el-polyton
+,#+LATEX_HEADER: \usepackage[french,AUTO]{polyglossia}
+#+end_example
+
+This would produce in LaTeX (with the actual =polyglossia= syntax):
+
+#+begin_example
+\usepackage{polyglossia}
+\setmainlanguage[variant=polytonic]{greek}
+\setotherlanguage{french}
+#+end_example
+
 *** Quoting LaTeX code
 :PROPERTIES:
 :DESCRIPTION: Incorporating literal @LaTeX{} code.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 00fe101dc..fc9ac688a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -431,6 +431,19 @@ prompting for a link description.  It can be a string (used as-is) or
 a function (called with the same arguments as
 ~org-make-link-description-function~ to return a string to use).
 
+*** New list of languages for LaTeX export: ~org-latex-language-alist~ 
+
+~org-latex-language-alist~ unifies into a single list the old language
+lists for the =babel= and =polyglossia= LaTeX packages:
+~org-latex-babel-language-alist~ and
+~org-latex-polyglossia-language-alist~, respectively, which are
+declared obsolete.
+
+This new list captures the current state of art regarding language
+support in LaTeX.  The new =babel= syntax for loading languages via
+=ini= files and the new command =\babelprovide= (see:
+http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf)
+are also supported.
 * Version 9.5
 
 ** Important announcements and breaking changes
-- 
2.37.2


^ permalink raw reply related	[relevance 8%]

* Re: [PATCH] Documentation and NEWS for ` org-latex-language-alist'
  2022-08-08 14:39  9% [PATCH] Documentation and NEWS for ` org-latex-language-alist' Juan Manuel Macías
  2022-08-09 11:43  5% ` Ihor Radchenko
@ 2022-08-09 15:39  6% ` Max Nikulin
  1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2022-08-09 15:39 UTC (permalink / raw)
  To: emacs-orgmode

On 08/08/2022 21:39, Juan Manuel Macías wrote:
> 
> I am attaching a patch with the documentation of the new variable in the
> Manual and the updated NEWS.

> +  =\babelprovide= command (see
> +  http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf).
> +  Valid usage examples could be:

Firefox may block downloading of a file through unencrypted http: 
protocol if a link is opened from a https: page (HTML version of the Org 
manual served from orgmode.org this case). The problem with CTAN mirrors 
is that not all hosts have TLS certificates including their CTAN names.



^ permalink raw reply	[relevance 6%]

* Re: [PATCH] Documentation and NEWS for ` org-latex-language-alist'
  2022-08-08 14:39  9% [PATCH] Documentation and NEWS for ` org-latex-language-alist' Juan Manuel Macías
@ 2022-08-09 11:43  5% ` Ihor Radchenko
  2022-08-16 14:16  8%   ` Juan Manuel Macías
  2022-08-09 15:39  6% ` [PATCH] Documentation and NEWS for ` org-latex-language-alist' Max Nikulin
  1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-08-09 11:43 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

Juan Manuel Macías <maciaschain@posteo.net> writes:

> I am attaching a patch with the documentation of the new variable in the
> Manual and the updated NEWS.

Thanks!

I tried to apply your patch and read the relevant section of the manual
from the beginning. I feel that the new wording is awkward.
The patch is adding text to LaTeX export settings section where
individual #+KEYWORDS are discussed. Yet, the patch goes deeply into
setting some variables from the very beginning only providing a single
example where the #+LANGUAGE keyword is actually used.

I attached the screenshot of HTML version of the manual for clarity.


[-- Attachment #2: exported-patch-as-it-reads.png --]
[-- Type: image/png, Size: 220253 bytes --]

[-- Attachment #3: Type: text/plain, Size: 613 bytes --]


I feel like we should first describe what #+LANGUAGE keyword does and
go into the gory details of LaTeX language support a bit later.

Basically, I am asking you to reshuffle paragraphs a bit possibly moving
some parts to more relevant 13.10.3 LaTeX header and sectioning
structure. People have no idea about #+LATEX_HEADER when reading 13.10.2
LaTeX specific export settings (coming before the 13.10.3).

-- 
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%]

* [PATCH] Documentation and NEWS for ` org-latex-language-alist'
@ 2022-08-08 14:39  9% Juan Manuel Macías
  2022-08-09 11:43  5% ` Ihor Radchenko
  2022-08-09 15:39  6% ` [PATCH] Documentation and NEWS for ` org-latex-language-alist' Max Nikulin
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-08 14:39 UTC (permalink / raw)
  To: orgmode

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

Hi,

I am attaching a patch with the documentation of the new variable in the
Manual and the updated NEWS.

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-doc-org-manual.org-documentation-for-org-latex-langu.patch --]
[-- Type: text/x-patch, Size: 4540 bytes --]

From 2ec740e4b2f691f619878a7b86e4874fa05d3a82 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 8 Aug 2022 16:30:01 +0200
Subject: [PATCH] doc/org-manual.org: documentation for
 `org-latex-language-alist'

* etc/ORG-NEWS: update the news with the new variable.
---
 doc/org-manual.org | 57 ++++++++++++++++++++++++++++++++++++++++++++--
 etc/ORG-NEWS       | 13 +++++++++++
 2 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 466718e6e..5d0283bf2 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13370,19 +13370,72 @@ general options (see [[*Export Settings]]).
 - =LANGUAGE= ::
   #+cindex: @samp{LANGUAGE}, keyword
   #+vindex: org-latex-packages-alist
+  #+vindex: org-latex-language-alist
+  #+vindex: org-export-default-language
+  
+  The list of languages supported by Org is stored in the variable
+  ~org-latex-language-alist~.
+
   In order to be effective, the =babel= or =polyglossia=
   packages---according to the LaTeX compiler used---must be loaded
   with the appropriate language as argument.  This can be accomplished
   by modifying the ~org-latex-packages-alist~ variable, e.g., with the
-  following snippet:
+  following snippet (note that =polyglossia= does not work with
+  pdfLaTeX):
 
   #+begin_src emacs-lisp
   (add-to-list 'org-latex-packages-alist
-               '("AUTO" "babel" t ("pdflatex")))
+               '("AUTO" "babel" t ("pdflatex" "xelatex" "lualatex")))
   (add-to-list 'org-latex-packages-alist
                '("AUTO" "polyglossia" t ("xelatex" "lualatex")))
   #+end_src
 
+  LaTeX packages =babel= or =polyglossia= can also be loaded in a
+  document.  The "AUTO" string will be replaced in both cases by the
+  appropiate value for the =LANGUAGE= keyword, if present in the
+  document, or by the value of ~org-export-default-language~.  Let's
+  see some examples in one or another case.
+
+  =Babel= accepts the classic syntax and (in addition) the new syntax
+  with the =\babelprovide= command to load the languages using the new
+  =INI= files procedure.  Keep in mind that there are a number of
+  languages that are only served in babel using =INI= files, so they
+  cannot be declared using the classic syntax, but only using the
+  =\babelprovide= command (see
+  http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf).
+  Valid usage examples could be:
+
+  #+begin_example
+  ,#+LATEX_HEADER: \usepackage[french,italian,AUTO]{babel}
+  #+end_example
+
+  where "AUTO" is the main language.  But it can also be loaded using
+  the =\babelprovide= command:
+
+  #+begin_example
+  ,#+LATEX_HEADER: \usepackage[french,italian]{babel}
+  ,#+LATEX_HEADER: \babelprovide[import, main]{AUTO}
+  #+end_example
+
+  =Polyglossia=, for this procedure to be effective, must be loaded
+  using the same =babel= classic syntax (but note that /this is not/
+  the actual polyglossia syntax).  For example, suppose a document
+  declares Polytonic Greek as the primary language, and French as the
+  secondary language.  In this case, it would be expressed as:
+
+  #+begin_example
+  ,#+LANGUAGE: el-polyton
+  ,#+LATEX_HEADER: \usepackage[french,AUTO]{polyglossia}
+  #+end_example
+
+  This would produce in LaTeX (with the actual =polyglossia= syntax):
+
+  #+begin_example
+  \usepackage{polyglossia}
+  \setmainlanguage[variant=polytonic]{greek}
+  \setotherlanguage{french}
+  #+end_example
+
 - =LATEX_CLASS= ::
 
   #+cindex: @samp{LATEX_CLASS}, keyword
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 00fe101dc..fc9ac688a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -431,6 +431,19 @@ prompting for a link description.  It can be a string (used as-is) or
 a function (called with the same arguments as
 ~org-make-link-description-function~ to return a string to use).
 
+*** New list of languages for LaTeX export: ~org-latex-language-alist~ 
+
+~org-latex-language-alist~ unifies into a single list the old language
+lists for the =babel= and =polyglossia= LaTeX packages:
+~org-latex-babel-language-alist~ and
+~org-latex-polyglossia-language-alist~, respectively, which are
+declared obsolete.
+
+This new list captures the current state of art regarding language
+support in LaTeX.  The new =babel= syntax for loading languages via
+=ini= files and the new command =\babelprovide= (see:
+http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf)
+are also supported.
 * Version 9.5
 
 ** Important announcements and breaking changes
-- 
2.37.1


^ permalink raw reply related	[relevance 9%]

* Re: org-verse-num: display verse numbers within a verse block
  2022-08-07 14:22 13%   ` Juan Manuel Macías
  2022-08-07 14:44  6%     ` Jeremie Juste
@ 2022-08-07 15:16  6%     ` Ihor Radchenko
  1 sibling, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-08-07 15:16 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: m43cap, orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> BTW, is there any proprietary JavaScript free alternative to
> GitLab/GitHub? I would be very grateful for any recommendations.

For self-hosted solutions, you may check out https://gitea.io/en-us/

-- 
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 6%]

* Re: org-verse-num: display verse numbers within a verse block
  2022-08-07 14:22 13%   ` Juan Manuel Macías
@ 2022-08-07 14:44  6%     ` Jeremie Juste
  2022-08-07 15:16  6%     ` Ihor Radchenko
  1 sibling, 0 replies; 200+ results
From: Jeremie Juste @ 2022-08-07 14:44 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: m43cap, orgmode, Ihor Radchenko

Hello Juan,

On Sunday,  7 Aug 2022 at 14:22, Juan Manuel Macías wrote:

> I've added some minor improvements to my little package 'org-verse-num',
> which was born out of necessity in my translation to spanish
> (work-in-progress) of Homer's Odyssey (11600 verses spread over 24
> books):

> https://gitlab.com/maciaschain/org-verse-num

Many thanks for sharing.

>
> Sorry for the inconvenience. I plan to set up my own GitLab instance in
> the future, but I don't have time to do it anytime soon.
>
> BTW, is there any proprietary JavaScript free alternative to
> GitLab/GitHub? I would be very grateful for any recommendations.

https://sourcehut.org/ seems to gain popularity, but they charge a
fee. But it might still be less expensive than hosting your own gitlab
repository. (I have no affiliation with sourcehut and I am not an expert).

>
> (I noticed that my previous message was sent to the duplicate list.
> Apologies for that).

No problem for posting to two lists. I didn't know about emacs-humanities
<emacs-humanities@gnu.org>.


Best regards,
Jeremie


^ permalink raw reply	[relevance 6%]

* Re: org-verse-num: display verse numbers within a verse block
  2022-08-07 13:39  0% ` Colin Baxter
@ 2022-08-07 14:22 13%   ` Juan Manuel Macías
  2022-08-07 14:44  6%     ` Jeremie Juste
  2022-08-07 15:16  6%     ` Ihor Radchenko
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-07 14:22 UTC (permalink / raw)
  To: m43cap; +Cc: orgmode, Ihor Radchenko

Colin Baxter writes:

> Your site tells me to turn JavaScript, enable Cookies and complete a
> CAPTCHA, all of which I refuse to do.
>
> Do you have an alternative web-site?

Sorry for the inconvenience. I plan to set up my own GitLab instance in
the future, but I don't have time to do it anytime soon.

BTW, is there any proprietary JavaScript free alternative to
GitLab/GitHub? I would be very grateful for any recommendations.

(I noticed that my previous message was sent to the duplicate list.
Apologies for that).

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: org-verse-num: display verse numbers within a verse block
  2022-08-07 12:53 13% org-verse-num: display verse numbers within a verse block Juan Manuel Macías
@ 2022-08-07 13:39  0% ` Colin Baxter
  2022-08-07 14:22 13%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Colin Baxter @ 2022-08-07 13:39 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, emacs-humanities

>>>>> Juan Manuel Macías <maciaschain@posteo.net> writes:

    > Hi all, I've added some minor improvements to my little package
    > 'org-verse-num', which was born out of necessity in my translation
    > to spanish (work-in-progress) of Homer's Odyssey (11600 verses
    > spread over 24 books):

    > https://gitlab.com/maciaschain/org-verse-num

Your site tells me to turn JavaScript, enable Cookies and complete a
CAPTCHA, all of which I refuse to do.

Do you have an alternative web-site?


^ permalink raw reply	[relevance 0%]

* org-verse-num:  display verse numbers within a verse block
@ 2022-08-07 12:53 13% Juan Manuel Macías
  2022-08-07 13:39  0% ` Colin Baxter
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-08-07 12:53 UTC (permalink / raw)
  To: orgmode; +Cc: emacs-humanities

Hi all,

I've added some minor improvements to my little package 'org-verse-num',
which was born out of necessity in my translation to spanish
(work-in-progress) of Homer's Odyssey (11600 verses spread over 24
books):

https://gitlab.com/maciaschain/org-verse-num

org-verse-num includes some functions and a minor mode to aid in
navigating through (very) long poems within an Org-mode verse block. It
displays verse numbers sequentially (avoiding empty lines between
stanzas) and you can also move the cursor to a specific verse number.

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: [PATCH] ox-latex.el: `org-latex-language-alist' improved
  2022-08-06  7:13  5%     ` Ihor Radchenko
@ 2022-08-06 21:32 13%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-06 21:32 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> FYI, there is display-fill-column-indicator-mode, which is useful to
> guide the docstring in Elisp. Just need to set fill-column to 80.
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e47bcb02133608e37bc4c532aec4d4723f8eeca8

Thanks a lot for the suggestion, Ihor. With this I also realize that 90%
of my functions have the first line of the docstring too long...

Best regards,

Juan Manuel 


--
--
------------------------------------------------------
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com


^ permalink raw reply	[relevance 13%]

* Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved
  2022-08-04 10:04  3%   ` Juan Manuel Macías
  2022-08-04 12:16  7%     ` Max Nikulin
@ 2022-08-06  7:13  5%     ` Ihor Radchenko
  2022-08-06 21:32 13%       ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-08-06  7:13 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> I am attaching a new fixed version of the patch. If everything is ok, I
> get down to work with the Manual and NEWS. I think it would be nice to
> add a few usage examples, and some links to the Babel and Polyglossia
> documentation.

Applied onto main via e47bcb021 with minor amendments: I fixed a typo
"polyglosia" and shortened the first line of a docstring to less than 80
chars.

FYI, there is display-fill-column-indicator-mode, which is useful to
guide the docstring in Elisp. Just need to set fill-column to 80.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e47bcb02133608e37bc4c532aec4d4723f8eeca8

-- 
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: [PATCH] ox-latex.el: `org-latex-language-alist' improved
  2022-08-04 12:16  7%     ` Max Nikulin
@ 2022-08-05 17:14  9%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-05 17:14 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

Max Nikulin writes:

> Likely never variant is ideal. Maybe language should be always in
> :babel and :babel-ini-only should be boolean. I am not sure though
> that it will not make code more complex in other places, so feel free
> to ignore this comment.

What you say makes a lot of sense. Really the only reason why I avoided
doing something like that was rather the economy, so I didn't have to
put things like (two properties instead of one):

:babel xx :babel-ini-only t etc.

It is also expected that babel-ini-only is a 'temporary' property. At
least I would like it to be so.

According to the Babel documentation:

> Babel is moving gradually from the old and fuzzy concept of language
> to the more modern of locale.

Which is precisely what the new ini files are meant for. Now these files
can only be loaded via \babelprovide or by adding provide=* (and some
other variants) to the babel arguments (this last option is not
supported by my patch, for pdfLaTeX compatibility, where ini files don't
work. I imagine that when that transition is complete, there will be a
more inclusive and universal interface in babel. 

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved
  2022-08-04 10:04  3%   ` Juan Manuel Macías
@ 2022-08-04 12:16  7%     ` Max Nikulin
  2022-08-05 17:14  9%       ` Juan Manuel Macías
  2022-08-06  7:13  5%     ` Ihor Radchenko
  1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2022-08-04 12:16 UTC (permalink / raw)
  To: emacs-orgmode

On 04/08/2022 17:04, Juan Manuel Macías wrote:
>>> Subject: [PATCH] lisp/ox-latex.el: `org-latex-language-alist'
>> improved.

Thank you, Juan Manuel. The patch looks like what I was trying to 
suggest. However I have not tried to implement fontenc on the top of it.

> +				    (format "\\1\\2%s}"
> +					    (or language language-ini-only))

Likely never variant is ideal. Maybe language should be always in :babel 
and :babel-ini-only should be boolean. I am not sure though that it will 
not make code more complex in other places, so feel free to ignore this 
comment.



^ permalink raw reply	[relevance 7%]

* Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved
  2022-08-03 11:23  5% ` Ihor Radchenko
@ 2022-08-04 10:04  3%   ` Juan Manuel Macías
  2022-08-04 12:16  7%     ` Max Nikulin
  2022-08-06  7:13  5%     ` Ihor Radchenko
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-04 10:04 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

Hi, Ihor,

Ihor Radchenko writes:

> Thanks! I have some minor comments on the patch.
>
>> From b06cdd45198f470a135efad2cd1d8b22ab7e2f22 Mon Sep 17 00:00:00
> 2001
>> From: Juan Manuel Macias <maciaschain@posteo.net>
>> Date: Sun, 31 Jul 2022 02:31:08 +0200
>> Subject: [PATCH] lisp/ox-latex.el: `org-latex-language-alist'
> improved.
>
> No dot after the firs message line, please.
>
>> +  '(("am" . (:babel-ini-only "amharic" :polyglossia "amharic" :
> lang-name "Amharic"))
>> +    ("ar" . (:babel "arabic" :polyglossia "arabic" :lang-name
> "Arabic"))
>
> A simpler form would be
> ("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name
> "Amharic")
>
>> +    "Alist between language code and corresponding properties, such
>> +as Babel/Polyglossia options and language names.
>
> The first line of the docstring should fit 80 characters and be a full
> sentence. It is needed to make sure that eldoc can display the short
> docstring in the message area.
>
>> +- `:poliglosia' the name of the language loaded by the Polyglossia
> LaTeX package
>
> `:polyglossia', I think.
>
>> +- `:babel-ini-only' the name of the language loaded by Babel
>> +  exclusively through the new ini files method.
>
> May we put some kind of reference to LaTeX docs here?
>
>> +  (let ((language (let* ((lang (plist-get info :language))
>> + (plist (cdr
>> + (assoc lang org-latex-language-alist))))
>> +                    ;; Here the actual name of the LANGUAGE or LANG
> is used
>
> Please end the comment sentence with ".".

Thanks for your comments and patience, and sorry again for the typos.

I am attaching a new fixed version of the patch. If everything is ok, I
get down to work with the Manual and NEWS. I think it would be nice to
add a few usage examples, and some links to the Babel and Polyglossia
documentation.

Best regards,

Juan Manuel 



[-- Attachment #2: 0001-lisp-ox-latex.el-org-latex-language-alist-improved.patch --]
[-- Type: text/x-patch, Size: 18544 bytes --]

From 3d67d46cfc3e2f4a8feab1fed0598912700118a6 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Thu, 4 Aug 2022 11:54:01 +0200
Subject: [PATCH] lisp/ox-latex.el: `org-latex-language-alist' improved

* (org-latex-language-alist): Alist between language code and
corresponding properties, such as Babel/Polyglossia options and
language names.  Each element of the list consists of a cons cell,
where car is the language code and cdr is a property list.
* (org-latex-guess-babel-language): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
* (org-latex-guess-polyglossia-language): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
* (org-latex--format-spec): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
---
 lisp/ox-latex.el | 290 +++++++++++++++++++++++------------------------
 1 file changed, 140 insertions(+), 150 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index c56f9d347..69d01b9c7 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -173,110 +173,107 @@
 ;;; Internal Variables
 
 (defconst org-latex-language-alist
-  ;; TODO: replace this list with a property list (the actual
-  ;; implementation is not very robust).
-  '(("am" "amharic" "*")
-    ("ar" "arabic")
-    ("ast" "asturian" "*")
-    ("bg" "bulgarian")
-    ("bn" "bengali" "*")
-    ("bo" "tibetan" "*")
-    ("br" "breton")
-    ("ca" "catalan")
-    ("cop" "coptic" "*")
-    ("cs" "czech")
-    ("cy" "welsh")
-    ("da" "danish")
-    ("de" "ngerman" "german" "german")
-    ("de-at" "naustrian" "german" "austrian")
-    ("dsb" "lsorbian" "*")
-    ("dv" "divehi" "*")
-    ("el" "greek")
-    ("el-polyton" "polutonikogreek" "greek" "polytonic")
-    ("en" "american" "english" "usmax")
-    ("en-au" "australian" "english" "australian")
-    ("en-gb" "british" "english" "uk")
-    ("en-nz" "newzealand" "english" "newzealand")
-    ("en-us" "american" "english" "usmax")
-    ("eo" "esperanto")
-    ("es" "spanish")
-    ("es-mx" "spanishmx" "spanish" "mexican")
-    ("et" "estonian")
-    ("eu" "basque")
-    ("fa" "farsi")
-    ("fi" "finnish")
-    ("fr" "french")
-    ("fr-ca" "canadien" "french" "canadian")
-    ("fur" "friulan")
-    ("ga" "irish")
-    ("gd" "scottish")
-    ("gl" "galician")
-    ("he" "hebrew")
-    ("hi" "hindi")
-    ("hr" "croatian")
-    ("hsb" "uppersorbian" "sorbian" "upper")
-    ("hu" "magyar")
-    ("hy" "armenian" "*")
-    ("ia" "interlingua")
-    ("id" "bahasai" "*")
-    ("is" "icelandic")
-    ("it" "italian")
-    ("kn" "kannada" "*")
-    ("la" "latin")
-    ("la-classic" "classiclatin" "latin" "classic")
-    ("la-medieval" "medievallatin" "latin" "medieval")
-    ("la-ecclesiastic" "ecclesiasticlatin" "latin" "ecclesiastic")
-    ("lo" "lao" "*")
-    ("lt" "lithuanian")
-    ("lv" "latvian")
-    ("ml" "malayalam" "*")
-    ("mr" "maranthi" "*")
-    ("nb" "norsk" "norwegian" "bokmal")
-    ("nl" "dutch")
-    ("nn" "nynorsk" "norwegian" "nynorsk")
-    ("no" "norsk")
-    ("oc" "occitan")
-    ("pl" "polish")
-    ("pms" "piedmontese")
-    ("pt" "portuges")
-    ("pt-br" "brazilian")
-    ("rm" "romansh" "*")
-    ("ro" "romanian")
-    ("ru" "russian")
-    ("sa" "sanskrit" "*")
-    ("sk" "slovak")
-    ("sl" "slovene")
-    ("sq" "albanian")
-    ("sr" "serbian")
-    ("sv" "swedish")
-    ("syr" "syriac" "*")
-    ("ta" "tamil" "*")
-    ("te" "telugu" "*")
-    ("th" "thai")
-    ("tk" "turkmen")
-    ("tr" "turkish")
-    ("uk" "ukrainian")
-    ("ur" "urdu" "*")
-    ("vi" "vietnamese"))
-  "Alist between language code and corresponding Babel/Polyglossia option.
-
-For the names of the languages, the Babel nomenclature is
-preferred to that of Polyglossia, in those cases where both
-coincide.
-
-The alist supports three types of members:
-
-- Members with two elements: CODE BABEL/POLYGLOSSIA OPTION.
-
-- Members with three elements: CODE BABEL/POLYGLOSSIA OPTION
-ASTERISK (the presence of the asterisk indicates that this
-language is not loaded in Babel using the old method of ldf
-files but using ini files.  If Babel is loaded in an Org
-document with these languages, the \"AUTO \" argument is just
-removed, to avoid compilation errors).
-
-- Members with four elements (for variants of languages): CODE
-BABEL-OPTION POLYGLOSSIA-OPTION POLYGLOSSIA-VARIANT")
+  '(("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic")
+    ("ar" :babel "arabic" :polyglossia "arabic" :lang-name "Arabic")
+    ("ast" :babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian")
+    ("bg"  :babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian")
+    ("bn"  :babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali")
+    ("bo"  :babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan")
+    ("br"  :babel "breton" :polyglossia "breton" :lang-name "Breton")
+    ("ca"  :babel "catalan" :polyglossia "catalan" :lang-name "Catalan")
+    ("cop"  :babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic")
+    ("cs"  :babel "czech" :polyglossia "czech" :lang-name "Czech")
+    ("cy"  :babel "welsh" :polyglossia "welsh" :lang-name "Welsh")
+    ("da"  :babel "danish" :polyglossia "danish" :lang-name "Danish")
+    ("de"  :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
+    ("de-at"  :babel "naustrian" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German")
+    ("dsb"  :babel "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian")
+    ("dv"  :babel-ini-only "divehi" :polyglossia "divehi" :lang-name "Divehi")
+    ("el"  :babel "greek" :polyglossia "greek" :lang-name "Greek")
+    ("el-polyton"  :babel "polutonikogreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek")
+    ("en"  :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
+    ("en-au"  :babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English")
+    ("en-gb"  :babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English")
+    ("en-nz"  :babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English")
+    ("en-us"  :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
+    ("eo"  :babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto")
+    ("es"  :babel "spanish" :polyglossia "spanish" :lang-name "Spanish")
+    ("es-mx"  :babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish")
+    ("et"  :babel "estonian" :polyglossia "estonian" :lang-name "Estonian")
+    ("eu"  :babel "basque" :polyglossia "basque" :lang-name "Basque")
+    ("fa"  :babel "farsi" :polyglossia "farsi" :lang-name "Farsi")
+    ("fi"  :babel "finnish" :polyglossia "finnish" :lang-name "Finnish")
+    ("fr"  :babel "french" :polyglossia "french" :lang-name "French")
+    ("fr-ca"  :babel "canadien" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French")
+    ("fur"  :babel "friulan" :polyglossia "friulan" :lang-name "Friulian")
+    ("ga"  :babel "irish" :polyglossia "irish" :lang-name "Irish")
+    ("gd"  :babel "scottish" :polyglossia "scottish" :lang-name "Scottish Gaelic")
+    ("gl"  :babel "galician" :polyglossia "galician" :lang-name "Galician")
+    ("he"  :babel "hebrew" :polyglossia "hebrew" :lang-name "Hebrew")
+    ("hi"  :babel "hindi" :polyglossia "hindi" :lang-name "Hindi")
+    ("hr"  :babel "croatian" :polyglossia "croatian" :lang-name "Croatian")
+    ("hsb"  :babel "uppersorbian" :polyglossia "sorbian" :polyglossia-variant "upper" :lang-name "Upper Sorbian")
+    ("hu"  :babel "magyar" :polyglossia "magyar" :lang-name "Magyar")
+    ("hy"  :babel-ini-only "armenian" :polyglossia "armenian" :lang-name "Armenian")
+    ("ia"  :babel "interlingua" :polyglossia "interlingua" :lang-name "Interlingua")
+    ("id"  :babel-ini-only "bahasai" :polyglossia "bahasai" :lang-name "Bahasai")
+    ("is"  :babel "icelandic" :polyglossia "icelandic" :lang-name "Icelandic")
+    ("it"  :babel "italian" :polyglossia "italian" :lang-name "Italian")
+    ("kn"  :babel-ini-only "kannada" :polyglossia "kannada" :lang-name "Kannada")
+    ("la"  :babel "latin" :polyglossia "latin" :lang-name "Latin")
+    ("la-classic"  :babel "classiclatin" :polyglossia "latin" :polyglossia-variant "classic" :lang-name "Classic Latin")
+    ("la-medieval"  :babel "medievallatin" :polyglossia "latin" :polyglossia-variant "medieval" :lang-name "Medieval Latin")
+    ("la-ecclesiastic"  :babel "ecclesiasticlatin" :polyglossia "latin" :polyglossia-variant "ecclesiastic" :lang-name "Ecclesiastic Latin")
+    ("lo"  :babel-ini-only "lao" :polyglossia "lao" :lang-name "Lao")
+    ("lt"  :babel "lithuanian" :polyglossia "lithuanian" :lang-name "Lithuanian")
+    ("lv"  :babel "latvian" :polyglossia "latvian" :lang-name "Latvian")
+    ("ml"  :babel-ini-only "malayalam" :polyglossia "malayalam" :lang-name "Malayalam")
+    ("mr"  :babel-ini-only "maranthi" :polyglossia "maranthi" :lang-name "Maranthi")
+    ("nb"  :babel "norsk" :polyglossia "norwegian" :polyglossia-variant "bokmal" :lang-name "Norwegian Bokmål")
+    ("nl"  :babel "dutch" :polyglossia "dutch" :lang-name "Dutch")
+    ("nn"  :babel "nynorsk" :polyglossia "norwegian" :polyglossia-variant "nynorsk" :lang-name "Norwegian Nynorsk")
+    ("no"  :babel "norsk" :polyglossia "norsk" :lang-name "Norwegian")
+    ("oc"  :babel "occitan" :polyglossia "occitan" :lang-name "Occitan")
+    ("pl"  :babel "polish" :polyglossia "polish" :lang-name "Polish")
+    ("pms"  :babel "piedmontese" :polyglossia "piedmontese" :lang-name "Piedmontese")
+    ("pt"  :babel "portuges" :polyglossia "portuges" :lang-name "Portuges")
+    ("pt-br"  :babel "brazilian" :polyglossia "brazilian" :lang-name "Portuges")
+    ("rm"  :babel-ini-only "romansh" :polyglossia "romansh" :lang-name "Romansh")
+    ("ro"  :babel "romanian" :polyglossia "romanian" :lang-name "Romanian")
+    ("ru"  :babel "russian" :polyglossia "russian" :lang-name "Russian")
+    ("sa"  :babel-ini-only "sanskrit" :polyglossia "sanskrit" :lang-name "Sanskrit")
+    ("sk"  :babel "slovak" :polyglossia "slovak" :lang-name "Slovak")
+    ("sl"  :babel "slovene" :polyglossia "slovene" :lang-name "Slovene")
+    ("sq"  :babel "albanian" :polyglossia "albanian" :lang-name "Albanian")
+    ("sr"  :babel "serbian" :polyglossia "serbian" :lang-name "Serbian")
+    ("sv"  :babel "swedish" :polyglossia "swedish" :lang-name "Swedish")
+    ("syr"  :babel-ini-only "syriac" :polyglossia "syriac" :lang-name "Syriac")
+    ("ta"  :babel-ini-only "tamil" :polyglossia "tamil" :lang-name "Tamil")
+    ("te"  :babel-ini-only "telugu" :polyglossia "telugu" :lang-name "Telugu")
+    ("th"  :babel "thai" :polyglossia "thai" :lang-name "Thai")
+    ("tk"  :babel "turkmen" :polyglossia "turkmen" :lang-name "Turkmen")
+    ("tr"  :babel "turkish" :polyglossia "turkish" :lang-name "Turkish")
+    ("uk"  :babel "ukrainian" :polyglossia "ukrainian" :lang-name "Ukrainian")
+    ("ur"  :babel-ini-only "urdu" :polyglossia "urdu" :lang-name "Urdu")
+    ("vi"  :babel "vietnamese" :polyglossia "vietnamese" :lang-name "Vietnamese"))
+  "Alist between language code and corresponding properties for LaTeX export.
+
+In each element of the list car is always the code of the
+language and cdr is a property list.  Valid keywords for this
+list can be:
+
+- `:babel' the name of the language loaded by the Babel LaTeX package
+
+- `:polyglosia' the name of the language loaded by the Polyglossia LaTeX package
+
+- `:babel-ini-only' the name of the language loaded by Babel
+ exclusively through the new ini files method.  See
+ `http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf'
+
+- `:polyglossia-variant' the language variant loaded by Polyglossia
+
+- `:lang-name' the actual name of the language.")
+
 
 (defconst org-latex-table-matrix-macros '(("bordermatrix" . "\\cr")
 					  ("qbordermatrix" . "\\cr")
@@ -1619,11 +1616,15 @@ already loaded.
 
 Return the new header."
   (let* ((language-code (plist-get info :language))
-	 (language (nth 1 (assoc language-code
-				 org-latex-language-alist)))
-	 ;; If no language is set or Babel package is not loaded, return
- 	 ;; HEADER as-is.
-	 (header (if (or (not (stringp language-code))
+	 (plist (cdr
+		 (assoc language-code org-latex-language-alist)))
+	 (language (plist-get plist :babel))
+	 (language-ini-only (plist-get plist :babel-ini-only))
+	 ;; If no language is set, or Babel package is not loaded, or
+	 ;; LANGUAGE keyword value is a language served by Babel
+	 ;; exclusively through ini files, return HEADER as-is.
+	 (header (if (or language-ini-only
+			 (not (stringp language-code))
 			 (not (string-match "\\\\usepackage\\[\\(.*\\)\\]{babel}" header)))
 		     header
 		   (let ((options (save-match-data
@@ -1634,22 +1635,13 @@ Return the new header."
 		     ;; served in Babel exclusively through ini files are not added
 		     ;; to the babel argument, and must be loaded using
 		     ;; `\babelprovide'.
-		     (let ((l (assoc language-code org-latex-language-alist)))
-                       ;; Three elements imply that LANGUAGE is served
-                       ;; in Babel only by means of an ini file.
-                       ;; Therefore it will not be added to the Babel
-                       ;; argument.  TODO: this should be improved
-                       ;; when `org-latex-language-alist' is replaced
-                       ;; by a more robust list.
-		       (if (and (consp l) (= (length l) 3))
-                           header
-			 (replace-match
-			  (mapconcat (lambda (option) (if (equal "AUTO" option) language option))
-				     (cond ((member language options) (delete "AUTO" options))
-					   ((member "AUTO" options) options)
-					   (t (append options (list language))))
-				     ", ")
-			  t nil header 1)))))))
+		     (replace-match
+		      (mapconcat (lambda (option) (if (equal "AUTO" option) language option))
+				 (cond ((member language options) (delete "AUTO" options))
+				       ((member "AUTO" options) options)
+				       (t (append options (list language))))
+				 ", ")
+		      t nil header 1)))))
     ;; If `\babelprovide[args]{AUTO}' is present, AUTO is
     ;; replaced by LANGUAGE.
     (if (not (string-match "\\\\babelprovide\\[.*\\]{\\(.+\\)}" header))
@@ -1658,7 +1650,9 @@ Return the new header."
 	(when (equal "AUTO" prov)
 	  (replace-regexp-in-string (format
 				     "\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
-				    (format "\\1\\2%s}" language) header t))))))
+				    (format "\\1\\2%s}"
+					    (or language language-ini-only))
+				    header t))))))
 
 (defun org-latex-guess-polyglossia-language (header info)
   "Set the Polyglossia language according to the LANGUAGE keyword.
@@ -1675,13 +1669,13 @@ replaced with the language of the document or
 using \setdefaultlanguage and not as an option to the package.
 
 Return the new header."
-  (let ((language (plist-get info :language)))
+  (let* ((language (plist-get info :language)))
     ;; If no language is set or Polyglossia is not loaded, return
     ;; HEADER as-is.
     (if (or (not (stringp language))
 	    (not (string-match
-		"\\\\usepackage\\(?:\\[\\([^]]+?\\)\\]\\){polyglossia}\n"
-		header)))
+		  "\\\\usepackage\\(?:\\[\\([^]]+?\\)\\]\\){polyglossia}\n"
+		  header)))
 	header
       (let* ((options (org-string-nw-p (match-string 1 header)))
 	     (languages (and options
@@ -1700,23 +1694,20 @@ Return the new header."
 	 (concat "\\usepackage{polyglossia}\n"
 		 (mapconcat
 		  (lambda (l)
-		    (let ((l (or (assoc l org-latex-language-alist)
-				 l)))
-		      (format (if main-language-set "\\setotherlanguage%s{%s}\n"
+		    (let* ((plist (cdr
+				   (assoc language org-latex-language-alist)))
+			   (polyglossia-variant (plist-get plist :polyglossia-variant))
+			   (polyglossia-lang (plist-get plist :polyglossia))
+			   (l (if (equal l language)
+				  polyglossia-lang
+				l)))
+		      (format (if main-language-set (format "\\setotherlanguage{%s}\n" l)
 				(setq main-language-set t)
 				"\\setmainlanguage%s{%s}\n")
-                              ;; Four elements implies that there is a
-                              ;; variant (4) for LANGUAGE when
-                              ;; declared by Polyglossia (3).
-                              ;; FIXME: This should be improved when
-                              ;; `org-latex-language-alist' is
-                              ;; replaced by a more robust list.
-                              (if (and (consp l) (= (length l) 4))
-				  (format "[variant=%s]" (nth 3 l))
+			      (if polyglossia-variant
+				  (format "[variant=%s]" polyglossia-variant)
 				"")
-			      (if (and (consp l) (= (length l) 4))
-				  (nth 2 l)
-				(nth 1 l)))))
+			      l)))
 		  languages
 		  ""))
 	 t t header 0)))))
@@ -1860,13 +1851,12 @@ INFO is a plist used as a communication channel."
 (defun org-latex--format-spec (info)
   "Create a format-spec for document meta-data.
 INFO is a plist used as a communication channel."
-  (let ((language (let ((lang (plist-get info :language)))
-                    ;; The second element in
-                    ;; `org-latex-language-alist' is always the
-                    ;; language name, regardless of the type of the
-                    ;; alist entry.
-                    (or (nth 1 (assoc-string lang org-latex-language-alist t))
-			lang))))
+  (let ((language (let* ((lang (plist-get info :language))
+		         (plist (cdr
+			         (assoc lang org-latex-language-alist))))
+                    ;; Here the actual name of the LANGUAGE or LANG is used.
+		    (or (plist-get plist :lang-name)
+		        lang))))
     `((?a . ,(org-export-data (plist-get info :author) info))
       (?t . ,(org-export-data (plist-get info :title) info))
       (?s . ,(org-export-data (plist-get info :subtitle) info))
-- 
2.37.1


^ permalink raw reply related	[relevance 3%]

* Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved
  2022-07-31  1:00  3% [PATCH] ox-latex.el: `org-latex-language-alist' improved Juan Manuel Macías
@ 2022-08-03 11:23  5% ` Ihor Radchenko
  2022-08-04 10:04  3%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-08-03 11:23 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

Juan Manuel Macías <maciaschain@posteo.net> writes:

> I've managed to get some free time to remake this list, following Maxim
> Nikulin's suggestion
> (https://list.orgmode.org/orgmode/taeb0a$r62$1@ciao.gmane.io/). It's no
> longer an anonymous list and I agree it now has a more robust structure
> with name fields. I have also added the `:lang-name' property, whose
> value is the actual language name. For example:
>
> ("el-polyton" . (:babel "polutonikogreek" :polyglossia "greek"
> :polyglossia-variant "polytonic" :lang-name "Polytonic Greek"))
>
> Thanks to this I think the code for org-latex-guess-babel-language,
> org-latex-guess-polyglossia-language and org-latex--format-spec is also
> simpler.

Thanks! I have some minor comments on the patch.

> From b06cdd45198f470a135efad2cd1d8b22ab7e2f22 Mon Sep 17 00:00:00 2001
> From: Juan Manuel Macias <maciaschain@posteo.net>
> Date: Sun, 31 Jul 2022 02:31:08 +0200
> Subject: [PATCH] lisp/ox-latex.el: `org-latex-language-alist' improved.

No dot after the firs message line, please.

> +  '(("am" . (:babel-ini-only "amharic" :polyglossia "amharic" :lang-name
"Amharic"))
> +    ("ar" . (:babel "arabic" :polyglossia "arabic" :lang-name "Arabic"))

A simpler form would be
("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic")

> +    "Alist between language code and corresponding properties, such
> +as Babel/Polyglossia options and language names.

The first line of the docstring should fit 80 characters and be a full
sentence. It is needed to make sure that eldoc can display the short
docstring in the message area.

> +- `:poliglosia' the name of the language loaded by the Polyglossia LaTeX
package

`:polyglossia', I think.

> +- `:babel-ini-only' the name of the language loaded by Babel
> +  exclusively through the new ini files method.

May we put some kind of reference to LaTeX docs here?

> +  (let ((language (let* ((lang (plist-get info :language))
> + (plist (cdr
> + (assoc lang org-latex-language-alist))))
> +                    ;; Here the actual name of the LANGUAGE or LANG is
used

Please end the comment sentence with ".".

Best,
Ihor

[-- Attachment #2: Type: text/html, Size: 2843 bytes --]

^ permalink raw reply	[relevance 5%]

* [PATCH] ox-latex.el: `org-latex-language-alist' improved
@ 2022-07-31  1:00  3% Juan Manuel Macías
  2022-08-03 11:23  5% ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-31  1:00 UTC (permalink / raw)
  To: orgmode

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

Hi,

I've managed to get some free time to remake this list, following Maxim
Nikulin's suggestion
(https://list.orgmode.org/orgmode/taeb0a$r62$1@ciao.gmane.io/). It's no
longer an anonymous list and I agree it now has a more robust structure
with name fields. I have also added the `:lang-name' property, whose
value is the actual language name. For example:

("el-polyton" . (:babel "polutonikogreek" :polyglossia "greek"
:polyglossia-variant "polytonic" :lang-name "Polytonic Greek"))

Thanks to this I think the code for org-latex-guess-babel-language,
org-latex-guess-polyglossia-language and org-latex--format-spec is also
simpler.

Best regards,

Juan Manuel


[-- Attachment #2: 0001-lisp-ox-latex.el-org-latex-language-alist-improved.patch --]
[-- Type: text/x-patch, Size: 18752 bytes --]

From b06cdd45198f470a135efad2cd1d8b22ab7e2f22 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 31 Jul 2022 02:31:08 +0200
Subject: [PATCH] lisp/ox-latex.el: `org-latex-language-alist' improved.

* (org-latex-language-alist): Alist between language code and
corresponding properties, such as Babel/Polyglossia options and
language names.  Each element of the list consists of a cons cell,
where car is the language code and cdr is a property list.
* (org-latex-guess-babel-language): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
* (org-latex-guess-polyglossia-language): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
* (org-latex--format-spec): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
---
 lisp/ox-latex.el | 287 +++++++++++++++++++++++------------------------
 1 file changed, 138 insertions(+), 149 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index c56f9d347..669458913 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -173,110 +173,106 @@
 ;;; Internal Variables
 
 (defconst org-latex-language-alist
-  ;; TODO: replace this list with a property list (the actual
-  ;; implementation is not very robust).
-  '(("am" "amharic" "*")
-    ("ar" "arabic")
-    ("ast" "asturian" "*")
-    ("bg" "bulgarian")
-    ("bn" "bengali" "*")
-    ("bo" "tibetan" "*")
-    ("br" "breton")
-    ("ca" "catalan")
-    ("cop" "coptic" "*")
-    ("cs" "czech")
-    ("cy" "welsh")
-    ("da" "danish")
-    ("de" "ngerman" "german" "german")
-    ("de-at" "naustrian" "german" "austrian")
-    ("dsb" "lsorbian" "*")
-    ("dv" "divehi" "*")
-    ("el" "greek")
-    ("el-polyton" "polutonikogreek" "greek" "polytonic")
-    ("en" "american" "english" "usmax")
-    ("en-au" "australian" "english" "australian")
-    ("en-gb" "british" "english" "uk")
-    ("en-nz" "newzealand" "english" "newzealand")
-    ("en-us" "american" "english" "usmax")
-    ("eo" "esperanto")
-    ("es" "spanish")
-    ("es-mx" "spanishmx" "spanish" "mexican")
-    ("et" "estonian")
-    ("eu" "basque")
-    ("fa" "farsi")
-    ("fi" "finnish")
-    ("fr" "french")
-    ("fr-ca" "canadien" "french" "canadian")
-    ("fur" "friulan")
-    ("ga" "irish")
-    ("gd" "scottish")
-    ("gl" "galician")
-    ("he" "hebrew")
-    ("hi" "hindi")
-    ("hr" "croatian")
-    ("hsb" "uppersorbian" "sorbian" "upper")
-    ("hu" "magyar")
-    ("hy" "armenian" "*")
-    ("ia" "interlingua")
-    ("id" "bahasai" "*")
-    ("is" "icelandic")
-    ("it" "italian")
-    ("kn" "kannada" "*")
-    ("la" "latin")
-    ("la-classic" "classiclatin" "latin" "classic")
-    ("la-medieval" "medievallatin" "latin" "medieval")
-    ("la-ecclesiastic" "ecclesiasticlatin" "latin" "ecclesiastic")
-    ("lo" "lao" "*")
-    ("lt" "lithuanian")
-    ("lv" "latvian")
-    ("ml" "malayalam" "*")
-    ("mr" "maranthi" "*")
-    ("nb" "norsk" "norwegian" "bokmal")
-    ("nl" "dutch")
-    ("nn" "nynorsk" "norwegian" "nynorsk")
-    ("no" "norsk")
-    ("oc" "occitan")
-    ("pl" "polish")
-    ("pms" "piedmontese")
-    ("pt" "portuges")
-    ("pt-br" "brazilian")
-    ("rm" "romansh" "*")
-    ("ro" "romanian")
-    ("ru" "russian")
-    ("sa" "sanskrit" "*")
-    ("sk" "slovak")
-    ("sl" "slovene")
-    ("sq" "albanian")
-    ("sr" "serbian")
-    ("sv" "swedish")
-    ("syr" "syriac" "*")
-    ("ta" "tamil" "*")
-    ("te" "telugu" "*")
-    ("th" "thai")
-    ("tk" "turkmen")
-    ("tr" "turkish")
-    ("uk" "ukrainian")
-    ("ur" "urdu" "*")
-    ("vi" "vietnamese"))
-  "Alist between language code and corresponding Babel/Polyglossia option.
-
-For the names of the languages, the Babel nomenclature is
-preferred to that of Polyglossia, in those cases where both
-coincide.
-
-The alist supports three types of members:
-
-- Members with two elements: CODE BABEL/POLYGLOSSIA OPTION.
-
-- Members with three elements: CODE BABEL/POLYGLOSSIA OPTION
-ASTERISK (the presence of the asterisk indicates that this
-language is not loaded in Babel using the old method of ldf
-files but using ini files.  If Babel is loaded in an Org
-document with these languages, the \"AUTO \" argument is just
-removed, to avoid compilation errors).
-
-- Members with four elements (for variants of languages): CODE
-BABEL-OPTION POLYGLOSSIA-OPTION POLYGLOSSIA-VARIANT")
+  '(("am" . (:babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic"))
+    ("ar" . (:babel "arabic" :polyglossia "arabic" :lang-name "Arabic"))
+    ("ast" . (:babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian"))
+    ("bg"  . (:babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian"))
+    ("bn"  . (:babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali"))
+    ("bo"  . (:babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan"))
+    ("br"  . (:babel "breton" :polyglossia "breton" :lang-name "Breton"))
+    ("ca"  . (:babel "catalan" :polyglossia "catalan" :lang-name "Catalan"))
+    ("cop"  . (:babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic"))
+    ("cs"  . (:babel "czech" :polyglossia "czech" :lang-name "Czech"))
+    ("cy"  . (:babel "welsh" :polyglossia "welsh" :lang-name "Welsh"))
+    ("da"  . (:babel "danish" :polyglossia "danish" :lang-name "Danish"))
+    ("de"  . (:babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German"))
+    ("de-at"  . (:babel "naustrian" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German"))
+    ("dsb"  . (:babel "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian"))
+    ("dv"  . (:babel-ini-only "divehi" :polyglossia "divehi" :lang-name "Divehi"))
+    ("el"  . (:babel "greek" :polyglossia "greek" :lang-name "Greek"))
+    ("el-polyton"  . (:babel "polutonikogreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek"))
+    ("en"  . (:babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English"))
+    ("en-au"  . (:babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English"))
+    ("en-gb"  . (:babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English"))
+    ("en-nz"  . (:babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English"))
+    ("en-us"  . (:babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English"))
+    ("eo"  . (:babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto"))
+    ("es"  . (:babel "spanish" :polyglossia "spanish" :lang-name "Spanish"))
+    ("es-mx"  . (:babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish"))
+    ("et"  . (:babel "estonian" :polyglossia "estonian" :lang-name "Estonian"))
+    ("eu"  . (:babel "basque" :polyglossia "basque" :lang-name "Basque"))
+    ("fa"  . (:babel "farsi" :polyglossia "farsi" :lang-name "Farsi"))
+    ("fi"  . (:babel "finnish" :polyglossia "finnish" :lang-name "Finnish"))
+    ("fr"  . (:babel "french" :polyglossia "french" :lang-name "French"))
+    ("fr-ca"  . (:babel "canadien" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French"))
+    ("fur"  . (:babel "friulan" :polyglossia "friulan" :lang-name "Friulian"))
+    ("ga"  . (:babel "irish" :polyglossia "irish" :lang-name "Irish"))
+    ("gd"  . (:babel "scottish" :polyglossia "scottish" :lang-name "Scottish Gaelic"))
+    ("gl"  . (:babel "galician" :polyglossia "galician" :lang-name "Galician"))
+    ("he"  . (:babel "hebrew" :polyglossia "hebrew" :lang-name "Hebrew"))
+    ("hi"  . (:babel "hindi" :polyglossia "hindi" :lang-name "Hindi"))
+    ("hr"  . (:babel "croatian" :polyglossia "croatian" :lang-name "Croatian"))
+    ("hsb"  . (:babel "uppersorbian" :polyglossia "sorbian" :polyglossia-variant "upper" :lang-name "Upper Sorbian"))
+    ("hu"  . (:babel "magyar" :polyglossia "magyar" :lang-name "Magyar"))
+    ("hy"  . (:babel-ini-only "armenian" :polyglossia "armenian" :lang-name "Armenian"))
+    ("ia"  . (:babel "interlingua" :polyglossia "interlingua" :lang-name "Interlingua"))
+    ("id"  . (:babel-ini-only "bahasai" :polyglossia "bahasai" :lang-name "Bahasai"))
+    ("is"  . (:babel "icelandic" :polyglossia "icelandic" :lang-name "Icelandic"))
+    ("it"  . (:babel "italian" :polyglossia "italian" :lang-name "Italian"))
+    ("kn"  . (:babel-ini-only "kannada" :polyglossia "kannada" :lang-name "Kannada"))
+    ("la"  . (:babel "latin" :polyglossia "latin" :lang-name "Latin"))
+    ("la-classic"  . (:babel "classiclatin" :polyglossia "latin" :polyglossia-variant "classic" :lang-name "Classic Latin"))
+    ("la-medieval"  . (:babel "medievallatin" :polyglossia "latin" :polyglossia-variant "medieval" :lang-name "Medieval Latin"))
+    ("la-ecclesiastic"  . (:babel "ecclesiasticlatin" :polyglossia "latin" :polyglossia-variant "ecclesiastic" :lang-name "Ecclesiastic Latin"))
+    ("lo"  . (:babel-ini-only "lao" :polyglossia "lao" :lang-name "Lao"))
+    ("lt"  . (:babel "lithuanian" :polyglossia "lithuanian" :lang-name "Lithuanian"))
+    ("lv"  . (:babel "latvian" :polyglossia "latvian" :lang-name "Latvian"))
+    ("ml"  . (:babel-ini-only "malayalam" :polyglossia "malayalam" :lang-name "Malayalam"))
+    ("mr"  . (:babel-ini-only "maranthi" :polyglossia "maranthi" :lang-name "Maranthi"))
+    ("nb"  . (:babel "norsk" :polyglossia "norwegian" :polyglossia-variant "bokmal" :lang-name "Norwegian Bokmål"))
+    ("nl"  . (:babel "dutch" :polyglossia "dutch" :lang-name "Dutch"))
+    ("nn"  . (:babel "nynorsk" :polyglossia "norwegian" :polyglossia-variant "nynorsk" :lang-name "Norwegian Nynorsk"))
+    ("no"  . (:babel "norsk" :polyglossia "norsk" :lang-name "Norwegian"))
+    ("oc"  . (:babel "occitan" :polyglossia "occitan" :lang-name "Occitan"))
+    ("pl"  . (:babel "polish" :polyglossia "polish" :lang-name "Polish"))
+    ("pms"  . (:babel "piedmontese" :polyglossia "piedmontese" :lang-name "Piedmontese"))
+    ("pt"  . (:babel "portuges" :polyglossia "portuges" :lang-name "Portuges"))
+    ("pt-br"  . (:babel "brazilian" :polyglossia "brazilian" :lang-name "Portuges"))
+    ("rm"  . (:babel-ini-only "romansh" :polyglossia "romansh" :lang-name "Romansh"))
+    ("ro"  . (:babel "romanian" :polyglossia "romanian" :lang-name "Romanian"))
+    ("ru"  . (:babel "russian" :polyglossia "russian" :lang-name "Russian"))
+    ("sa"  . (:babel-ini-only "sanskrit" :polyglossia "sanskrit" :lang-name "Sanskrit"))
+    ("sk"  . (:babel "slovak" :polyglossia "slovak" :lang-name "Slovak"))
+    ("sl"  . (:babel "slovene" :polyglossia "slovene" :lang-name "Slovene"))
+    ("sq"  . (:babel "albanian" :polyglossia "albanian" :lang-name "Albanian"))
+    ("sr"  . (:babel "serbian" :polyglossia "serbian" :lang-name "Serbian"))
+    ("sv"  . (:babel "swedish" :polyglossia "swedish" :lang-name "Swedish"))
+    ("syr"  . (:babel-ini-only "syriac" :polyglossia "syriac" :lang-name "Syriac"))
+    ("ta"  . (:babel-ini-only "tamil" :polyglossia "tamil" :lang-name "Tamil"))
+    ("te"  . (:babel-ini-only "telugu" :polyglossia "telugu" :lang-name "Telugu"))
+    ("th"  . (:babel "thai" :polyglossia "thai" :lang-name "Thai"))
+    ("tk"  . (:babel "turkmen" :polyglossia "turkmen" :lang-name "Turkmen"))
+    ("tr"  . (:babel "turkish" :polyglossia "turkish" :lang-name "Turkish"))
+    ("uk"  . (:babel "ukrainian" :polyglossia "ukrainian" :lang-name "Ukrainian"))
+    ("ur"  . (:babel-ini-only "urdu" :polyglossia "urdu" :lang-name "Urdu"))
+    ("vi"  . (:babel "vietnamese" :polyglossia "vietnamese" :lang-name "Vietnamese"))
+    "Alist between language code and corresponding properties, such
+as Babel/Polyglossia options and language names.
+
+Each element of the list consists of a cons cell, where car is
+the language code and cdr is a property list.  Valid keywords for
+this list can be:
+
+- `:babel' the name of the language loaded by the Babel LaTeX package
+
+- `:poliglosia' the name of the language loaded by the Polyglossia LaTeX package
+
+- `:babel-ini-only' the name of the language loaded by Babel
+  exclusively through the new ini files method.
+
+- `:polyglossia-variant' the language variant loaded by Polyglossia
+
+- `:lang-name' the actual name of the language."))
 
 (defconst org-latex-table-matrix-macros '(("bordermatrix" . "\\cr")
 					  ("qbordermatrix" . "\\cr")
@@ -1619,11 +1615,15 @@ already loaded.
 
 Return the new header."
   (let* ((language-code (plist-get info :language))
-	 (language (nth 1 (assoc language-code
-				 org-latex-language-alist)))
-	 ;; If no language is set or Babel package is not loaded, return
- 	 ;; HEADER as-is.
-	 (header (if (or (not (stringp language-code))
+	 (plist (cdr
+		 (assoc language-code org-latex-language-alist)))
+	 (language (plist-get plist :babel))
+	 (language-ini-only (plist-get plist :babel-ini-only))
+	 ;; If no language is set, or Babel package is not loaded, or
+	 ;; LANGUAGE keyword value is a language served by Babel
+	 ;; exclusively through ini files, return HEADER as-is.
+	 (header (if (or language-ini-only
+			 (not (stringp language-code))
 			 (not (string-match "\\\\usepackage\\[\\(.*\\)\\]{babel}" header)))
 		     header
 		   (let ((options (save-match-data
@@ -1634,22 +1634,13 @@ Return the new header."
 		     ;; served in Babel exclusively through ini files are not added
 		     ;; to the babel argument, and must be loaded using
 		     ;; `\babelprovide'.
-		     (let ((l (assoc language-code org-latex-language-alist)))
-                       ;; Three elements imply that LANGUAGE is served
-                       ;; in Babel only by means of an ini file.
-                       ;; Therefore it will not be added to the Babel
-                       ;; argument.  TODO: this should be improved
-                       ;; when `org-latex-language-alist' is replaced
-                       ;; by a more robust list.
-		       (if (and (consp l) (= (length l) 3))
-                           header
-			 (replace-match
-			  (mapconcat (lambda (option) (if (equal "AUTO" option) language option))
-				     (cond ((member language options) (delete "AUTO" options))
-					   ((member "AUTO" options) options)
-					   (t (append options (list language))))
-				     ", ")
-			  t nil header 1)))))))
+		     (replace-match
+		      (mapconcat (lambda (option) (if (equal "AUTO" option) language option))
+				 (cond ((member language options) (delete "AUTO" options))
+				       ((member "AUTO" options) options)
+				       (t (append options (list language))))
+				 ", ")
+		      t nil header 1)))))
     ;; If `\babelprovide[args]{AUTO}' is present, AUTO is
     ;; replaced by LANGUAGE.
     (if (not (string-match "\\\\babelprovide\\[.*\\]{\\(.+\\)}" header))
@@ -1658,7 +1649,9 @@ Return the new header."
 	(when (equal "AUTO" prov)
 	  (replace-regexp-in-string (format
 				     "\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
-				    (format "\\1\\2%s}" language) header t))))))
+				    (format "\\1\\2%s}"
+					    (or language language-ini-only))
+				    header t))))))
 
 (defun org-latex-guess-polyglossia-language (header info)
   "Set the Polyglossia language according to the LANGUAGE keyword.
@@ -1675,13 +1668,13 @@ replaced with the language of the document or
 using \setdefaultlanguage and not as an option to the package.
 
 Return the new header."
-  (let ((language (plist-get info :language)))
+  (let* ((language (plist-get info :language)))
     ;; If no language is set or Polyglossia is not loaded, return
     ;; HEADER as-is.
     (if (or (not (stringp language))
 	    (not (string-match
-		"\\\\usepackage\\(?:\\[\\([^]]+?\\)\\]\\){polyglossia}\n"
-		header)))
+		  "\\\\usepackage\\(?:\\[\\([^]]+?\\)\\]\\){polyglossia}\n"
+		  header)))
 	header
       (let* ((options (org-string-nw-p (match-string 1 header)))
 	     (languages (and options
@@ -1700,23 +1693,20 @@ Return the new header."
 	 (concat "\\usepackage{polyglossia}\n"
 		 (mapconcat
 		  (lambda (l)
-		    (let ((l (or (assoc l org-latex-language-alist)
-				 l)))
-		      (format (if main-language-set "\\setotherlanguage%s{%s}\n"
+		    (let* ((plist (cdr
+				   (assoc language org-latex-language-alist)))
+			   (polyglossia-variant (plist-get plist :polyglossia-variant))
+			   (polyglossia-lang (plist-get plist :polyglossia))
+			   (l (if (equal l language)
+				  polyglossia-lang
+				l)))
+		      (format (if main-language-set (format "\\setotherlanguage{%s}\n" l)
 				(setq main-language-set t)
 				"\\setmainlanguage%s{%s}\n")
-                              ;; Four elements implies that there is a
-                              ;; variant (4) for LANGUAGE when
-                              ;; declared by Polyglossia (3).
-                              ;; FIXME: This should be improved when
-                              ;; `org-latex-language-alist' is
-                              ;; replaced by a more robust list.
-                              (if (and (consp l) (= (length l) 4))
-				  (format "[variant=%s]" (nth 3 l))
+			      (if polyglossia-variant
+				  (format "[variant=%s]" polyglossia-variant)
 				"")
-			      (if (and (consp l) (= (length l) 4))
-				  (nth 2 l)
-				(nth 1 l)))))
+			      l)))
 		  languages
 		  ""))
 	 t t header 0)))))
@@ -1860,12 +1850,11 @@ INFO is a plist used as a communication channel."
 (defun org-latex--format-spec (info)
   "Create a format-spec for document meta-data.
 INFO is a plist used as a communication channel."
-  (let ((language (let ((lang (plist-get info :language)))
-                    ;; The second element in
-                    ;; `org-latex-language-alist' is always the
-                    ;; language name, regardless of the type of the
-                    ;; alist entry.
-                    (or (nth 1 (assoc-string lang org-latex-language-alist t))
+  (let ((language (let* ((lang (plist-get info :language))
+			 (plist (cdr
+				 (assoc lang org-latex-language-alist))))
+                    ;; Here the actual name of the LANGUAGE or LANG is used
+		    (or (plist-get plist :lang-name)
 			lang))))
     `((?a . ,(org-export-data (plist-get info :author) info))
       (?t . ,(org-export-data (plist-get info :title) info))
-- 
2.37.1


^ permalink raw reply related	[relevance 3%]

* Re: [PATCH] Add new entity \-- serving as markup separator/escape symbol
  @ 2022-07-29  0:32  8%           ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-29  0:32 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Hi, Ihor,

Ihor Radchenko writes:

> Given the raised objections, zero-width space does not appear to be a
> useful escape symbol because it has its valid uses as a standalone space
> symbol.
>
> The raised objections can be solved using some kind of intricate
> heuristics, but I do not feel like it is a good direction to go. The
> code will be too complex and fragile.
>
> Therefore, I am proposing a different approach for shielding
> fontification: introducing a special entity.
>
> The new entity is \--, which is a valid boundary between emphasis
> markup. It will be removed during export (replaced by "").
>
> "\--" specifically is somewhat arbitrary choice. The actual requirements
> for the entity name are: (1) No clash with LaTeX (which is why simpler
> \- would not cut it); (2) Being a valid markup boundary: entity must end
> with (any space ?- ?\( ?' ?\" ?\{).
>
> I am attaching a tentative patch introducing the new entity. Note that
> some minor tweaks to the parser were needed. I do not see it as a big
> deal - the current entity regexp has much more cumbersome exceptions.
>
> Also, the patch will not work correctly on org → org export, similar to
> pointed in one of the replies to the previous abandoned approach. I do
> not want to address it here because a much more appropriate solution for
> this issue is changing org-element-interpret-data.
>
> Consider (org-element-interpret-data '("asd" (bold () "bold") "bsd"))
> This will return "asd*bold*bsd", which is not correct even though the
> given Org datum is not wrong by itself - such things can easily appear
> when user filters are applied to parse tree during org→org export.
>
> Otherwise, the patch should be good enough to play around and kick-start
> the discussion.

I'm late joining this thread, although I am particularly interested in
the topic.

I can't make any technical comments because I haven't had time to test
the patch yet, but I have to say that your idea of using a special
entity seems to me the best approach to the problem. I would vote for
this to be the way to go.

I believe that using the zero width space character as an escape
character is not a happy idea, and I have already left my arguments in
some other thread, long ago. The zero width space is a random
workaround, but should not (in my opinion) be part of the markup. For
various reasons: it is not an ascii character, there are certain
contexts in which it can produce an unexpected result in LaTeX, etc. In
addition, the zero width space, as an escape character, has a curious
anomaly: it is an escape character that does not have a plan B and a way
to escape the escape character when you want to use it by itself.

I also like the idea of using a special entity because it is not
necessary to invent anything new and it takes advantage of an existing
resource.

Well, that's my opinion.

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 8%]

* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
  2022-07-26 16:19  9%                   ` Juan Manuel Macías
@ 2022-07-28 12:36  6%                     ` Ihor Radchenko
  0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-07-28 12:36 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> A thousand apologies for my horrible carelessness with the parentheses.
> I should have checked the code. Here goes the patch again corrected. I
> hope it's alright now.

Thanks!
Applied onto main via d37c0ee5f after adding full stop after sentences
in the commit message and amending some wording.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d37c0ee5fa7dc4be4bbe3aa9b6f4e79d4b1e638d

Best,
Ihor


^ permalink raw reply	[relevance 6%]

* Re: [PATCH] org-export: Remove zero-width space escapes during export
  @ 2022-07-27  3:30  5%         ` Max Nikulin
    1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2022-07-27  3:30 UTC (permalink / raw)
  To: emacs-orgmode

On 26/07/2022 19:59, Ihor Radchenko wrote:
> 
> I am attaching a tentative patch that will make Org export remove
> zero-width spaces when those spaces actually separate the object
> boundaries.

Ihor, I have realized that you did not address another use case: zero 
width spaces may be added to suppress activation of markup. In such 
cases they are in the middle of text objects, but they should be removed.

     Switch to the *​scratch​* buffer.

I consider zero width spaces as a workaround that is acceptable in some 
cases but awkward in others. It is tricky to deal with it in some 
general way.

I do not agree with the stance "just maintain status quo" expressed in 
response to Juan Manuel Macías. On zero width spaces and Org syntax. 
Fri, 03 Dec 2021 12:48:16 +0000 
https://list.orgmode.org/orgmode/87ilw5yhv3.fsf@posteo.net/

An idea. At certain moment I was surprised that markup markers are not 
activated at the borders of export snippets:

     intra@@org:@@*w*@@org:@@ord

It is not really lightweight markup but at least it is purely ASCII and 
visible by default. It might be breaking change in some edge cases. I am 
unsure concerning increasing complexity of the parser. Macro markers 
{{{macro}}} have similar behavior.



^ permalink raw reply	[relevance 5%]

* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
  2022-07-26 11:58  6%                 ` Ihor Radchenko
@ 2022-07-26 16:19  9%                   ` Juan Manuel Macías
  2022-07-28 12:36  6%                     ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-26 16:19 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

Hi Ihor,

A thousand apologies for my horrible carelessness with the parentheses.
I should have checked the code. Here goes the patch again corrected. I
hope it's alright now.

Ihor Radchenko writes:

> Also, the original code contained the clause:
> (or (get lang from the alist1)
>     (get lang from the alist2)
>     lang ; Fallback to provided language if not known.
>     )
>
> Your variant does not have the fallback part. Is it intentional?

Yes, I removed it because I thought it was not necessary, because after
all the user must put a supported language as the value of #+language.
Anyway, in case it breaks something backwards I have replaced it. Now
the or expression is:

(or (nth 1 (assoc-string lang org-latex-language-alist t))
	lang)

Best regards,

Juan Manuel 


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Remove-Babel-and-Polyglossia-alists.patch --]
[-- Type: text/x-patch, Size: 1324 bytes --]

From 483cf69e0ca56c560c3bd53db13887a63d529ec9 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 26 Jul 2022 18:01:52 +0200
Subject: [PATCH] lisp/ox-latex.el: Remove Babel and Polyglossia alists

* (org-latex--format-spec): The new variable is now `org-latex-language-alist'
---
 lisp/ox-latex.el | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 121a3f84c..14728f0ba 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1861,8 +1861,10 @@ INFO is a plist used as a communication channel."
   "Create a format-spec for document meta-data.
 INFO is a plist used as a communication channel."
   (let ((language (let ((lang (plist-get info :language)))
-		    (or (cdr (assoc-string lang org-latex-babel-language-alist t))
-			(nth 1 (assoc-string lang org-latex-polyglossia-language-alist t))
+                    ;; Here it would suffice to obtain the second
+                    ;; element, which always returns the name
+                    ;; language name in `org-latex-language-alist'
+                    (or (nth 1 (assoc-string lang org-latex-language-alist t))
 			lang))))
     `((?a . ,(org-export-data (plist-get info :author) info))
       (?t . ,(org-export-data (plist-get info :title) info))
-- 
2.37.1


^ permalink raw reply related	[relevance 9%]

* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
  @ 2022-07-26 11:58  6%                 ` Ihor Radchenko
  2022-07-26 16:19  9%                   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-07-26 11:58 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Here is the new patch. I have realized that it is not necessary to put a
> cond, since in this case it is only necessary to obtain the name of the
> language for the metadata, so this new patch is simpler.

Thanks for the update!

The patch has some misplaced parenthesis.

> -  (let ((language (let ((lang (plist-get info :language)))
> -		    (or (cdr (assoc-string lang org-latex-babel-language-alist t))
> -			(nth 1 (assoc-string lang org-latex-polyglossia-language-alist t))
> -			lang))))
> +  (let ((language (let ((lang (plist-get info :language))
> +                        ;; Here it would suffice to obtain the second
> +                        ;; element, which always returns the name
> +                        ;; language name in `org-latex-language-alist'
> +			(nth 1 (assoc-string lang org-latex-language-alist t))))))

Your (nth 1 ...) sexp is inside the let definition:
(let ((lang ...)
      (nth 1 ..))
  nil)

Please pay attention to the compiler warnings.

Also, the original code contained the clause:
(or (get lang from the alist1)
    (get lang from the alist2)
    lang ; Fallback to provided language if not known.
    )

Your variant does not have the fallback part. Is it intentional?

Best,
Ihor


^ permalink raw reply	[relevance 6%]

* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
  @ 2022-07-26  5:35  4%                 ` Ihor Radchenko
  0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-07-26  5:35 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Ihor Radchenko writes:
>
>>> -			 (org-back-to-heading t) ; Sets match data
>>> -			 (match-end 0))
>>> +			 (re-search-backward org-heading-regexp) ; Sets match data
>>> +			 (match-beginning 0))
>>
>> This will err when the source block is before the first headline in the
>> document.
>
> I've reverted the first line to (org-back-to-heading t), keeping the
> (match-beginning 0), otherwise you don't get the full headline and all
> property drawers would be exported. But it's strange, it doesn't give me
> any error when the source block is before the first headline in the
> document. Isn't that error prevented with this:
>
> (condition-case nil
> ...		   
> (error (point-min)))
>
> ?

Hmm. You are indeed right. I missed the condition-case part.
In any case, re-search-backward is not reliable when you have inlinetasks.

> By the way, I've noticed that it's not convenient to export numbered
> headers, so I've modified org-babel-export-comment-text-as-plain-text so
> that it removes header numbering. I don't know if it's ok to do it this
> way...

The path you took is indeed a bit awkward.
You may need to use the approach similar to orgtbl-to-latex.
Also, things to watch are org-export-exclude-tags,
org-export-with-section-numbers, org-export-with-archived-trees,
org-export-with-broken-links (we don't want tangle to fail because of
broken links), org-export-with-inlinetasks, org-export-with-toc,
and org-export-with-tasks.

> +(defun org-babel-export-comment-text-as-plain-text (text)
> +  "Function to process raw Org TEXT collected to be inserted as
> +comments in tangled source-code files.  This function is the
> +default value for `org-babel-process-comment-text'."
> +  ;; Ensure that if TEXT is a header it is not numbered.
> +  (let ((text-nonum (with-temp-buffer
> +                      (insert text)
> +                      (when (not (org-entry-get nil "UNNUMBERED"))
> +                        (org-entry-put nil "UNNUMBERED" "t"))
> +                      (buffer-string))))
> +    (org-export-string-as text-nonum 'ascii t)))

"Function to" can be safely dropped. See D.6 Tips for Documentation
Strings in Elisp manual:

   • The first line of the documentation string should consist of one or
     two complete sentences that stand on their own as a summary.  ‘M-x
     apropos’ displays just the first line, and if that line’s contents
     don’t stand on their own, the result looks bad.  In particular,
     start the first line with a capital letter and end it with a
     period.

     For a function, the first line should briefly answer the question,
     “What does this function do?” For a variable, the first line should
     briefly answer the question, “What does this value mean?”

     Don’t limit the documentation string to one line; use as many lines
     as you need to explain the details of how to use the function or
     variable.  Please use complete sentences for the rest of the text
     too.

   • The first line should mention all the important arguments of the
     function, and should mention them in the order that they are
     written in a function call.  If the function has many arguments,
     then it is not feasible to mention them all in the first line; in
     that case, the first line should mention the first few arguments,
     including the most important arguments.

   • For consistency, phrase the verb in the first sentence of a
     function’s documentation string as an imperative—for instance, use
     “Return the cons of A and B.” in preference to “Returns the cons of
     A and B.” Usually it looks good to do likewise for the rest of the
     first paragraph.  Subsequent paragraphs usually look better if each
     sentence is indicative and has a proper subject.

Best,
Ihor


^ permalink raw reply	[relevance 4%]

Results 401-600 of ~1600   |  | 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-06-10 18:28     [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments' Juan Manuel Macías
2022-06-11  5:39     ` Ihor Radchenko
2022-06-11 11:20       ` Juan Manuel Macías
2022-06-14  3:58         ` Ihor Radchenko
2022-06-14 11:11           ` Juan Manuel Macías
2022-06-14 11:55             ` Ihor Radchenko
2022-07-21 13:44               ` Juan Manuel Macías
2022-07-25 13:34                 ` Ihor Radchenko
2022-07-25 17:13                   ` Juan Manuel Macías
2022-07-26  5:35  4%                 ` Ihor Radchenko
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  0%     ` 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-07-23 13:44     BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Kai von Fintel
2022-07-23 13:59     ` Ihor Radchenko
2022-07-23 14:07       ` Kai von Fintel
2022-07-23 14:22         ` Ihor Radchenko
2022-07-23 14:39           ` Kai von Fintel
2022-07-23 14:50             ` Ihor Radchenko
2022-07-23 15:53               ` Juan Manuel Macías
2022-07-24  7:15                 ` Ihor Radchenko
2022-07-24 11:29                   ` Juan Manuel Macías
2022-07-26 11:58  6%                 ` Ihor Radchenko
2022-07-26 16:19  9%                   ` Juan Manuel Macías
2022-07-28 12:36  6%                     ` Ihor Radchenko
2022-07-25 19:02     How to force markup without spaces K
2022-07-26  1:26     ` Ihor Radchenko
2022-07-26  2:23       ` Max Nikulin
2022-07-26  4:26         ` K K
2022-07-26 12:59           ` [PATCH] org-export: Remove zero-width space escapes during export Ihor Radchenko
2022-07-27  3:30  5%         ` Max Nikulin
2022-07-28 13:17             ` [PATCH] Add new entity \-- serving as markup separator/escape symbol Ihor Radchenko
2022-07-29  0:32  8%           ` Juan Manuel Macías
2022-07-31  1:00  3% [PATCH] ox-latex.el: `org-latex-language-alist' improved Juan Manuel Macías
2022-08-03 11:23  5% ` Ihor Radchenko
2022-08-04 10:04  3%   ` Juan Manuel Macías
2022-08-04 12:16  7%     ` Max Nikulin
2022-08-05 17:14  9%       ` Juan Manuel Macías
2022-08-06  7:13  5%     ` Ihor Radchenko
2022-08-06 21:32 13%       ` Juan Manuel Macías
2022-08-07 12:53 13% org-verse-num: display verse numbers within a verse block Juan Manuel Macías
2022-08-07 13:39  0% ` Colin Baxter
2022-08-07 14:22 13%   ` Juan Manuel Macías
2022-08-07 14:44  6%     ` Jeremie Juste
2022-08-07 15:16  6%     ` Ihor Radchenko
2022-08-08 14:39  9% [PATCH] Documentation and NEWS for ` org-latex-language-alist' Juan Manuel Macías
2022-08-09 11:43  5% ` Ihor Radchenko
2022-08-16 14:16  8%   ` Juan Manuel Macías
2022-08-18 15:39  6%     ` Max Nikulin
2022-08-20  5:51  5%     ` Ihor Radchenko
2022-08-20  7:17           ` http: links in the manual Max Nikulin
2022-08-21  9:55  9%         ` Juan Manuel Macías
2022-08-22  2:46  6%           ` Auto-checking dead links in the manual (was: http: links in the manual) Ihor Radchenko
2022-08-22 15:29  0%             ` Max Nikulin
2022-08-09 15:39  6% ` [PATCH] Documentation and NEWS for ` org-latex-language-alist' Max Nikulin
2022-08-16 15:19  9% [off topic] List all non-latin characters in a buffer Juan Manuel Macías
2022-08-19 14:50  1% ` Uwe Brauer
2022-09-09 14:15  6%   ` Robert Pluim
2022-08-28 15:37     Have all the tags of a heading, with a tag hierarchy Cletip Cletip
2022-08-28 16:21 13% ` Juan Manuel Macías
2022-08-28 16:34  5%   ` Cletip Cletip
2022-09-06 12:25     Agenda 'Org view' (org-projection?) Eduardo Suarez
2022-09-06 14:21 13% ` Juan Manuel Macías
2022-09-13 15:54     error org export to pdf when latex letter class has been added to org-latex-classes M. Pger
2022-09-13 17:55 13% ` Juan Manuel Macías
2022-09-13 19:59  5%   ` M. Pger
2022-09-13 20:15 10%     ` Juan Manuel Macías
2022-09-18 12:27  9% [Patch] Pre-/postpend arbitrary LaTeX code to a section Juan Manuel Macías
2022-09-18 16:14  6% ` Max Nikulin
2022-09-19 10:04  5% ` Fraga, Eric
2022-09-20 13:26  5% ` Ihor Radchenko
2022-09-20 17:18 10%   ` Juan Manuel Macías
2022-09-21  8:55  5%     ` Ihor Radchenko
2022-09-21 13:55           ` Daniel Fleischer
2022-09-21 14:51 13%         ` Juan Manuel Macías
2022-09-21 14:43 10%       ` Juan Manuel Macías
2022-09-22 14:08  5%         ` Ihor Radchenko
2022-09-24 14:50 11%           ` Juan Manuel Macías
2022-09-25  3:33  6%             ` Ihor Radchenko
2022-09-25 12:06 10%               ` Juan Manuel Macías
2022-09-26  3:56  5%                 ` Ihor Radchenko
2022-09-26  7:47 13%                   ` Juan Manuel Macías
2022-09-19  8:59     Re " Pedro Andres Aranda Gutierrez
2022-09-20 13:19     ` Ihor Radchenko
2022-09-20 19:35 12%   ` Juan Manuel Macías
2022-09-25 15:30     Dynamic keybindings in the manual Timothy
2022-09-25 17:52  3% ` Juan Manuel Macías
     [not found]     <100cb12a-b3f1-739a-84f1-847f5e86a8bc@housseini.me>
2022-09-26 11:53     ` Extract toc from org file reza
2022-09-26 15:39 13%   ` 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  8% Create in Org a bilingual book with facing pages Juan Manuel Macías
2022-09-27 12:29  5% ` 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-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

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).