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: Exporting Org file to Html with collapsable headings
  @ 2022-01-22 18:20  0%     ` xincheng99
  0 siblings, 0 replies; 200+ results
From: xincheng99 @ 2022-01-22 18:20 UTC (permalink / raw)
  To: Max Nikulin, emacs-orgmode

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

Thanks a lot. This is very close to what I am looking for, and saves a lot of my time. I am grateful to all the help I received from this mailing list.

It is a lot of fun subscribing to this list.

Regards

Ziping

> On Jan 21, 2022, at 11:46 AM, Max Nikulin <manikulin_at_gmail_com_fcq2724cv3y0tc_re5x9491@icloud.com <mailto:manikulin_at_gmail_com_fcq2724cv3y0tc_re5x9491@icloud.com>> wrote:
> 
> On 21/01/2022 19:23, Juan Manuel Macías wrote:
>> ZIPING CHEN writes:
>>> I may have many things like this in the middle of the file.
>>> ************************** a new heading.
>>> 
>>> I wish to turn all layers of
>>> headings in org file into collapsable headline to html.
>>> 
>>> Does anybody know a way I can accomplish this?
>> I think that you need to add javascript and enclose the collapsible
>> content in a div. 
> 
> Have a look at info "(org) JavaScript support" https://orgmode.org/manual/JavaScript-support.html <https://orgmode.org/manual/JavaScript-support.html> (I have not tried that folding view).
> 
> HTML has <details><summary>header</summary>body</details> elements that works without JS, but it will require custom exporter.
> 
> You should ensure that deep headings can not be recognized as org inline tasks. Check ox-html, it may has limit on number of levels that are exported as headings with switching to lists for deeper structures.
> 
> 


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

^ permalink raw reply	[relevance 0%]

* Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
  @ 2022-01-24 12:09  9%       ` Juan Manuel Macías
  2022-01-24 12:32  6%         ` Vincent Belaïche
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-24 12:09 UTC (permalink / raw)
  To: Vincent Belaïche; +Cc: orgmode

Hi Vincent,

Vincent Belaïche writes:

> Hello,
>
> Sorry to dig out this almost 8 year old discussion, but after looking
> into the git HEAD Org Mode manual (v9.5 or so) (info "(org) Emphasis and
> Monospace") node, and after looking into the mail archive I could not
> find any answer to this question: how to switch style within a word.
>
> I would like to put something like this in an OrgMode document:
>
>  ~--some-cli-option=~/some cli argument/
>
> where the intent is that « --some-cli-option= » would be monospaced, and
> « some cli argument » would be italicized, and as you know this does not
> work this way.
>
>   Vincent.

It seems that this topic is already a classic :-) The supported solution
for intra-word emphases is to introduce a zero width space (U+200B), for
example:

~--some-cli-option=~[zero-width space]/some cli argument/

I don't really like this solution, but at least it works. If you export
to LaTeX, you may want to remove the space using a filter, as in some
(few) cases it can alter the LaTeX result.

The other realistic possibility is to use macros:

{{{mono(--some-cli-option=)}}}{{{emph(some cli argument)}}}

That is, more or less, the state of art. By the nature of its syntax,
emphasis between words is not possible in Org.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* RE: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
  2022-01-24 12:09  9%       ` Juan Manuel Macías
@ 2022-01-24 12:32  6%         ` Vincent Belaïche
    0 siblings, 1 reply; 200+ results
From: Vincent Belaïche @ 2022-01-24 12:32 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode


Hello,

Thank-you both for the reply, I should have mentioned that I am aware of
this trick but it works only for document encodings which have the
zero-width space, like UTF-8, I was after a fix for documents in
ISO-8859-15, aka latin-9.

  V.

De : Juan Manuel Macías <maciaschain@posteo.net>
Envoyé : lundi 24 janvier 2022 13:09
À : Vincent Belaïche <vincent.b.1@hotmail.fr>
Cc : orgmode <emacs-orgmode@gnu.org>
Objet : Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word** 
 
Hi Vincent,

Vincent Belaïche writes:

> Hello,
>
> Sorry to dig out this almost 8 year old discussion, but after looking
> into the git HEAD Org Mode manual (v9.5 or so) (info "(org) Emphasis and
> Monospace") node, and after looking into the mail archive I could not
> find any answer to this question: how to switch style within a word.
>
> I would like to put something like this in an OrgMode document:
>
>  ~--some-cli-option=~/some cli argument/
>
> where the intent is that « --some-cli-option= » would be monospaced, and
> « some cli argument » would be italicized, and as you know this does not
> work this way.
>
>   Vincent.

It seems that this topic is already a classic :-) The supported solution
for intra-word emphases is to introduce a zero width space (U+200B), for
example:

~--some-cli-option=~[zero-width space]/some cli argument/

I don't really like this solution, but at least it works. If you export
to LaTeX, you may want to remove the space using a filter, as in some
(few) cases it can alter the LaTeX result.

The other realistic possibility is to use macros:

{{{mono(--some-cli-option=)}}}{{{emph(some cli argument)}}}

That is, more or less, the state of art. By the nature of its syntax,
emphasis between words is not possible in Org.

Best regards,

Juan Manuel 

^ permalink raw reply	[relevance 6%]

* Re: Missing the second '}'
  @ 2022-01-24 16:46  9% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-24 16:46 UTC (permalink / raw)
  To: Sharon Kimble; +Cc: orgmode

Hi Sharon,

Sharon Kimble writes:

> Hi folks.
>
> In a document that I'm compiling I seem to have failed to close the '{'
> and '}', and the second one isn't in the document. If I write '\label{}'
> then it succeeds, but at a couple of places in the document this show
> '\label{'.
>
> How can I find where I've failed to close the brackets please, so that I
> can then achieve normality please?

Is this an Org document that you are exporting to LaTeX? If there is a
compile error, you can usually see it at the end of the *Org PDF LaTeX
Output* buffer. If it is a badly closed command, it is usually a
"Runaway argument?" warning, and the compiler indicates the problematic
line, which you should look for in the *.tex document. Sometimes it's
not easy to find the problem. The fastest way is to compile the *.tex
document directly with LaTeX and review the log file. It also usually
works to raise the position of \end{document} in the document. There
will come a point where it stops giving errors, and then the problem
will be easily located in the paragraph after \end{document}.

Best regards,

Juan Manuel 




^ permalink raw reply	[relevance 9%]

* Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**
  2022-01-25 17:18  3%             ` Vincent Belaïche
@ 2022-01-25 17:30  9%               ` Juan Manuel Macías
  2022-01-25 18:45  6%                 ` Vincent Belaïche
  2022-01-25 18:20  5%               ` Vincent Belaïche
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-25 17:30 UTC (permalink / raw)
  To: Vincent Belaïche; +Cc: orgmode

Hi Vincent,

Vincent Belaïche writes:

> My conlcusion is that for what I am after, an evolution of org-mode
> would be preferable, maybe I contribute something someday, so that
> writing one of the following would make it:
>
>    ~--my-option=~\relax{}/option value/
>    ~--my-option=~@@:@@/option value/
>    \left~--my-option=\right~/option value/
>    \left~--my-option=\right~\left/option value\right/
>    ~--my-option=~\left/option value\right/

Considering that Org's emphasis marks are not compromised by contact
with a single quote, I come up with this somewhat dirty solution: you
can use some kind of dummy mark (e.g. two single quotes: '') and put it
between the two emphasis parts. It would then be removed by a filter.
Something like this:

#+BIND: org-export-filter-final-output-functions (my-filter)

#+begin_src emacs-lisp :exports results :results none
  (defun my-filter (text backend info)
    (replace-regexp-in-string "''" "" text))
#+end_src


~some-cli-option=~''/some cli argument/

== LaTeX ==>

\texttt{some-cli-option=}\emph{some cli argument}

The solution is tricky and temporary, but at least it's not as
text-invasive as other options.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* RE: [RFC] Creole-style / Support for **emphasis**__within__**a word**
  @ 2022-01-25 17:18  3%             ` Vincent Belaïche
  2022-01-25 17:30  9%               ` Juan Manuel Macías
  2022-01-25 18:20  5%               ` Vincent Belaïche
  0 siblings, 2 replies; 200+ results
From: Vincent Belaïche @ 2022-01-25 17:18 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Juan Manuel Macías, orgmode

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

Hello,

Actually the source was in UTF-8, but it was using only characters that exist in latin-9, and it is exported to LaTeX for inclusion in a LaTeX document that is in latin-9.

So I used an Emacs lisp snippet to make the export, and in this snippet after calling something like  (org-export-to-buffer 'latex out-buffer nil nil nil t), I was doing some insertion like

      (goto-char (point-max))
      (insert "
% Local Variables:
% coding: latin-9
% End:
")
      (save-buffer)
      (kill-buffer)

so that the exported buffer is converted to latin-9 before being saved.

OK, when I inserted the zero width space this barked because of no zwsp (aka U+200B) in latin-9.

Then I tried something else, I rewrote the code with some some LaTeX snippet @@latex:\kern-0.5em\relax@@ in it, like this:

    ~--my-option=~ @@latex:\kern-0.5em\relax@@ /option value/

that was OK, but this really makes the OrgMode ugly (maybe a custom entity would be better), and also this works only for the LaTeX export.

Then, I tried something else, I passed « utf8,latin9 » options, to LaTeX inputenc package, instead of just « latin9 », and I kept my org mode document in UTF-8, just before exporting I did something like this in the input buffer:

    (goto-char (point-max))
    (insert "\n\n#+begin_export latex\n\\inputencoding{latin9}\n#+end_export\n")
    (goto-char (point-min))
    (insert "\n\n#+begin_export latex\n\\inputencoding{utf8}\n#+end_export\n")

this way the LaTeX processor is switching dynamically from latin9 to utf8 at the beginning of the doc, and back to latin9 at the end of it. But there are two pitfalls:

the first one is that zwsp are not defined in the inputenc utf8.def definition file, so having a zwsp character in the LaTeX code, even though utf8 is declared as input encoding make a LaTeX compilation error.

the second (but this is less serious I think …) is that my document ends with an enumerate list, and the orgmode exporter make the second begin_export go into the enumerate list, not after it. I mean I get in the output this:

   \inputencoding{latin9}
   \end{enumerate}

instead of this:

   \end{enumerate}
   \inputencoding{latin9}

My conlcusion is that for what I am after, an evolution of org-mode would be preferable, maybe I contribute something someday, so that writing one of the following would make it:

   ~--my-option=~\relax{}/option value/
   ~--my-option=~@@:@@/option value/
   \left~--my-option=\right~/option value/
   \left~--my-option=\right~\left/option value\right/
   ~--my-option=~\left/option value\right/


________________________________
De : Nicolas Goaziou <mail@nicolasgoaziou.fr>
Envoyé : mardi 25 janvier 2022 11:55
À : Vincent Belaïche <vincent.b.1@hotmail.fr>
Cc : Juan Manuel Macías <maciaschain@posteo.net>; orgmode <emacs-orgmode@gnu.org>
Objet : Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

Hello,

Vincent Belaïche <vincent.b.1@hotmail.fr> writes:

> Thank-you both for the reply, I should have mentioned that I am aware of
> this trick but it works only for document encodings which have the
> zero-width space, like UTF-8, I was after a fix for documents in
> ISO-8859-15, aka latin-9.

You mean the source itself is not UTF-8?

I don't think there's a solution for you then, unless you convert it to
UTF-8, of course.

Regards,
--
Nicolas Goaziou

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

^ permalink raw reply	[relevance 3%]

* RE: [RFC] Creole-style / Support for **emphasis**__within__**a word**
  2022-01-25 17:18  3%             ` Vincent Belaïche
  2022-01-25 17:30  9%               ` Juan Manuel Macías
@ 2022-01-25 18:20  5%               ` Vincent Belaïche
  1 sibling, 0 replies; 200+ results
From: Vincent Belaïche @ 2022-01-25 18:20 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Juan Manuel Macías, orgmode

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

Just replying to myself : the dynamic latin9/utf8 switch does not really easily work in a LaTeX document (I am sure some people made it work, but I did not manage to make it).

Adding the ZWSP support is easy, just insert

\DeclareUnicodeCharacter{200B}{}

in the document preamble, but this does not work because the table of content gets ugly with the titles likes « germe de générateur pseudo-aléatoire » instead of « germe de générateur pseudo-aléatoire » (some sections in the UTF-8 part going to the toc that is in the latin-9 part).

I tried to circumvent this by using the following encapsulation for the UTF-8 part :

\inputencoding{utf8}\addtocontents{toc}{\protect\inputencoding{utf8}}
...
\inputencoding{latin9}\addtocontents{toc}{\protect\inputencoding{latin9}}

(there are \addtocontents commands in addition to the \inputencoding so that I also switch the encoding in the toc file), but there are still issues, the dynamic switch does not work well with moving arguments like section titles going to the toc file. This is probably a problem of non-immediate write occurring at page shipout.

  V.

________________________________
De : Vincent Belaïche <vincent.b.1@hotmail.fr>
Envoyé : mardi 25 janvier 2022 18:18
À : Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc : Juan Manuel Macías <maciaschain@posteo.net>; orgmode <emacs-orgmode@gnu.org>
Objet : RE: [RFC] Creole-style / Support for **emphasis**__within__**a word**

Hello,

Actually the source was in UTF-8, but it was using only characters that exist in latin-9, and it is exported to LaTeX for inclusion in a LaTeX document that is in latin-9.

So I used an Emacs lisp snippet to make the export, and in this snippet after calling something like  (org-export-to-buffer 'latex out-buffer nil nil nil t), I was doing some insertion like

      (goto-char (point-max))
      (insert "
% Local Variables:
% coding: latin-9
% End:
")
      (save-buffer)
      (kill-buffer)

so that the exported buffer is converted to latin-9 before being saved.

OK, when I inserted the zero width space this barked because of no zwsp (aka U+200B) in latin-9.

Then I tried something else, I rewrote the code with some some LaTeX snippet @@latex:\kern-0.5em\relax@@ in it, like this:

    ~--my-option=~ @@latex:\kern-0.5em\relax@@ /option value/

that was OK, but this really makes the OrgMode ugly (maybe a custom entity would be better), and also this works only for the LaTeX export.

Then, I tried something else, I passed « utf8,latin9 » options, to LaTeX inputenc package, instead of just « latin9 », and I kept my org mode document in UTF-8, just before exporting I did something like this in the input buffer:

    (goto-char (point-max))
    (insert "\n\n#+begin_export latex\n\\inputencoding{latin9}\n#+end_export\n")
    (goto-char (point-min))
    (insert "\n\n#+begin_export latex\n\\inputencoding{utf8}\n#+end_export\n")

this way the LaTeX processor is switching dynamically from latin9 to utf8 at the beginning of the doc, and back to latin9 at the end of it. But there are two pitfalls:

the first one is that zwsp are not defined in the inputenc utf8.def definition file, so having a zwsp character in the LaTeX code, even though utf8 is declared as input encoding make a LaTeX compilation error.

the second (but this is less serious I think …) is that my document ends with an enumerate list, and the orgmode exporter make the second begin_export go into the enumerate list, not after it. I mean I get in the output this:

   \inputencoding{latin9}
   \end{enumerate}

instead of this:

   \end{enumerate}
   \inputencoding{latin9}

My conlcusion is that for what I am after, an evolution of org-mode would be preferable, maybe I contribute something someday, so that writing one of the following would make it:

   ~--my-option=~\relax{}/option value/
   ~--my-option=~@@:@@/option value/
   \left~--my-option=\right~/option value/
   \left~--my-option=\right~\left/option value\right/
   ~--my-option=~\left/option value\right/


________________________________
De : Nicolas Goaziou <mail@nicolasgoaziou.fr>
Envoyé : mardi 25 janvier 2022 11:55
À : Vincent Belaïche <vincent.b.1@hotmail.fr>
Cc : Juan Manuel Macías <maciaschain@posteo.net>; orgmode <emacs-orgmode@gnu.org>
Objet : Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

Hello,

Vincent Belaïche <vincent.b.1@hotmail.fr> writes:

> Thank-you both for the reply, I should have mentioned that I am aware of
> this trick but it works only for document encodings which have the
> zero-width space, like UTF-8, I was after a fix for documents in
> ISO-8859-15, aka latin-9.

You mean the source itself is not UTF-8?

I don't think there's a solution for you then, unless you convert it to
UTF-8, of course.

Regards,
--
Nicolas Goaziou

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

^ permalink raw reply	[relevance 5%]

* RE: [RFC] Creole-style / Support for **emphasis**__within__**a word**
  2022-01-25 17:30  9%               ` Juan Manuel Macías
@ 2022-01-25 18:45  6%                 ` Vincent Belaïche
  0 siblings, 0 replies; 200+ results
From: Vincent Belaïche @ 2022-01-25 18:45 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

Thank you so much Juan, I could adapt your filter to my needs, and this works like a charm !

  V.
________________________________
De : Juan Manuel Macías <maciaschain@posteo.net>
Envoyé : mardi 25 janvier 2022 18:30
À : Vincent Belaïche <vincent.b.1@hotmail.fr>
Cc : orgmode <emacs-orgmode@gnu.org>
Objet : Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

Hi Vincent,

Vincent Belaïche writes:

> My conlcusion is that for what I am after, an evolution of org-mode
> would be preferable, maybe I contribute something someday, so that
> writing one of the following would make it:
>
>    ~--my-option=~\relax{}/option value/
>    ~--my-option=~@@:@@/option value/
>    \left~--my-option=\right~/option value/
>    \left~--my-option=\right~\left/option value\right/
>    ~--my-option=~\left/option value\right/

Considering that Org's emphasis marks are not compromised by contact
with a single quote, I come up with this somewhat dirty solution: you
can use some kind of dummy mark (e.g. two single quotes: '') and put it
between the two emphasis parts. It would then be removed by a filter.
Something like this:

#+BIND: org-export-filter-final-output-functions (my-filter)

#+begin_src emacs-lisp :exports results :results none
  (defun my-filter (text backend info)
    (replace-regexp-in-string "''" "" text))
#+end_src


~some-cli-option=~''/some cli argument/

== LaTeX ==>

\texttt{some-cli-option=}\emph{some cli argument}

The solution is tricky and temporary, but at least it's not as
text-invasive as other options.

Best regards,

Juan Manuel

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

^ permalink raw reply	[relevance 6%]

* Re: latex block tikz to svg
  @ 2022-01-25 23:24  6%   ` Edouard Debry
  2022-04-18 13:23  4%   ` Edouard Debry
  1 sibling, 0 replies; 200+ results
From: Edouard Debry @ 2022-01-25 23:24 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode


Hi Juan,

Thanks for your answeer.

Indeed, the generated tex files are different whether you use the png or
svg extension.

It seems that for svg, a distinct build system is used from the usual
one for other image types (png, jpg).

This build system seems based on tex4ht, given the latex file preamble.

I tried to compile manually this temporary latex file (the one for svg)
with "pdflatex" which fails. Then, I tried with "htlatex" and guess what
... it works ! A svg file is created, which unfortunately does not
contain everything, but this was only manual compiling, probably some
missing options.

I think at first there may be a bug in my own configuration of the
variable "org-latex-pdf-process" which should be passed the correct
build system.

Regards

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

> Hi Edouard,
>
> Edouard Debry writes:
>
>> I would like to find a way to generate svg images from latex src blocks
>> (using tikz) which works and is compatible with default orgmode settings
>> for latex export (at least does not break it)
>>
>> Did you experience such issues ? do you have some workings settings and
>> examples ? I googled several times "org latex block tikz svg", but it is
>> difficult to guess how relevant are the elements found, some of them
>> seems quiet outdated. Hence my question on this mailing list
>
> I've done some quick tests with your example block. I don't know if I'm
> wrong, but I think the problem is on line 27 of `org-babel-execute:latex':
>
> ((string= "svg" extension)
>
> I don't know if this should be considered an Org bug, but it's clear
> that if the svg extension is detected in :file, the ':imagemagick yes'
> option is ignored, and a type of preamble is generated that fails in
> pgfsysdriver when compiling the temp tex document:
>
> \documentclass[preview]{standalone}
> \def\pgfsysdriver{pgfsys-tex4ht.def}
>
> If I replace the above line with this conditional:
>
> ((and (string= "svg" extension) (not imagemagick))
>
> then the imagemagick option is taken into account: it creates correctly
> the pdf and then converts it to svg with 'convert' imagemagick program.
> I did have to remove this line though:
>
> #+HEADER: :imoutoptions -geometry 400 :iminoptions -density 600
>
> otherwise, the conversion produced a dark image.
>
> Best regards,
>
> Juan Manuel 


^ permalink raw reply	[relevance 6%]

* Re: [PATCH] Intra-word markup: \relax
  @ 2022-01-28 13:13  9%   ` Juan Manuel Macías
  2022-02-02 15:42  5%     ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-28 13:13 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

Max Nikulin writes:

> I have an idea how to implement *intra*/word/ markup with minimal
> change of Org syntax. At first I had a hope that it is enough to
> introduce \relax entity that expands to empty string, but it does not
> work for second part of words: *intra*\relax{}/word/ is exported to
>     <b>intra</b>/word/.
> So it is necessary to support consuming spaces after such entity
> similar to TeX commands:
>     *intra*\relax /word/
> In Org "a\_      b" already behaves in the same way.
>
> I do not like zero-width spaces since they are invisible, so they are
> not really "text" markup. Moreover, it is better to filter them out 
> during export.
>
> Another failed idea was to use export snippet or a macro for such purpose:
>     #+macro sep $1
>     *intra*{{{sep()}}}/word/, *intra*@@html:@@/word/
>
> Important point that suggested solution works for all export backends.
> I do not consider explicit export snippets as a workaround since it 
> requires code for all backends in org files.

Maxim, I find the idea of \relax entity interesting. The only (minor)
drawback I find (in normal use, I mean) is the verbosity it adds.

In my case, I have already given up on the problem of marks inside words
:-(. My personal opinion: I think that, unless a completely
'revolutionary' solution emerges, it is better to leave the matter as it
is, and consider this a feature of Org rather than a bug. I suspect that
a single solution could not satisfy all tastes or all possible
scenarios, so maybe it would be nice to put a list of solutions
(including this one and also the zero space thing, and others that have
arisen or may arise) somewhere (perhaps in the manual?). What doesn't
quite convince me (and I agree with you on that) is recommending zero
width space as a sort of 'official' escape character. For the reasons
you have expressed, which I think are very fair.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: date format in agenda view
  2022-01-28 17:57 10% ` Juan Manuel Macías
@ 2022-01-28 18:05  0%   ` Uwe Brauer
  0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2022-01-28 18:05 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode

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

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

> Hi Uwe,
> Uwe Brauer writes:

>> How can I obtain the Spanish week names?

> I have this in my init:

> #+begin_src emacs-lisp
> (setq calendar-week-start-day 1
>       calendar-day-name-array ["domingo" "lunes" "martes" "miércoles"
> 			       "jueves" "viernes" "sábado"]
>       calendar-month-name-array ["enero" "febrero" "marzo" "abril" "mayo"
> 				 "junio" "julio" "agosto" "septiembre"
> 				 "octubre" "noviembre" "diciembre"])
> #+end_src

Ha, thanks, I just realized I have this setting but embedded in a function in order to switch between English, Spanish and German. Memory....☹️

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

^ permalink raw reply	[relevance 0%]

* Re: date format in agenda view
  @ 2022-01-28 17:57 10% ` Juan Manuel Macías
  2022-01-28 18:05  0%   ` Uwe Brauer
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-28 17:57 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode

Hi Uwe,

Uwe Brauer writes:

> How can I obtain the Spanish week names?

I have this in my init:

#+begin_src emacs-lisp
(setq calendar-week-start-day 1
      calendar-day-name-array ["domingo" "lunes" "martes" "miércoles"
			       "jueves" "viernes" "sábado"]
      calendar-month-name-array ["enero" "febrero" "marzo" "abril" "mayo"
				 "junio" "julio" "agosto" "septiembre"
				 "octubre" "noviembre" "diciembre"])
#+end_src

(https://www.emacswiki.org/emacs/CalendarLocalization#toc18)

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: Org-syntax: Intra-word markup
  @ 2022-01-29 13:05  9%                       ` Juan Manuel Macías
  2022-02-02 15:28  5%                         ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-29 13:05 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Maybe we should introduce an equivalent of special blocks, but for
> inline use? Or should we modify _both_ inline export snippets and export
> blocks to allow fallback mechanism?

I find the idea of inline special blocks very interesting, but I think
there are a couple of drawbacks: since special blocks support ATTR_X,
how would that be implemented in the inline version? The most obvious
thing I can think of is to mimic inline code blocks:

my_special_block[attributes list]{content}

But it would produce a result many times too verbose. Another risk that
this would entail, IMHO, is that of the "LaTeXification" of Org...

In any case, for things like that, aren't links and macros enough? I'm
one of those who 'abuse' links for many export scenarios (I even have
written this package:
https://gitlab.com/maciaschain/org-critical-edition), and I think links
have enormous potential and versatility. John Kitchin's blog has really
helped me open my mind and explore that very productive Org component.
Macros are also a very powerful tool, except for the comma issue, which
I think is still an unfinished business and a solution should be found
one day. Still, the possibility of a special inline block is very
interesting to me.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* A callygraphy notebook environment
@ 2022-01-30 12:32  9% Juan Manuel Macías
  2022-01-30 20:37  1% ` Uwe Brauer
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-30 12:32 UTC (permalink / raw)
  To: orgmode

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

Hi all,

This is more related to LaTeX than Org, but I'm sharing it here in case
anyone is interested. For a work I'm doing I've written a LaTeX
environment that tries to mimic the look of a calligraphy notebook. By
default it uses the qtmerryscript font, included in TeX live, but this
can be changed to any other calligraphic-style font. It works only with
LuaTeX, since it uses a function in Lua to add the grids.

An screenshots:

https://i.imgur.com/tgrgaWM.png

https://i.imgur.com/AIolze2.png

https://i.imgur.com/v2Mzyx5.png

To use it in Org, a special block would be ideal. For example:

#+ATTR_LaTeX: :options [fontfeature={Color=pen},fontsize=\large]
#+begin_mynotebook
Some text...
#+end_mynotebook

I am attaching an Org document to test it.

Best regards,

Juan Manuel


[-- Attachment #2: notebook.org --]
[-- Type: application/vnd.lotus-organizer, Size: 3824 bytes --]

^ permalink raw reply	[relevance 9%]

* Re: A callygraphy notebook environment
  2022-01-30 12:32  9% A callygraphy notebook environment Juan Manuel Macías
@ 2022-01-30 20:37  1% ` Uwe Brauer
  2022-01-30 21:23  9%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-01-30 20:37 UTC (permalink / raw)
  To: emacs-orgmode

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

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

> This is more related to LaTeX than Org, but I'm sharing it here in case
> anyone is interested. For a work I'm doing I've written a LaTeX
> environment that tries to mimic the look of a calligraphy notebook. By
> default it uses the qtmerryscript font, included in TeX live, but this
> can be changed to any other calligraphic-style font. It works only with
> LuaTeX, since it uses a function in Lua to add the grids.

> An screenshots:

> https://i.imgur.com/tgrgaWM.png

> https://i.imgur.com/AIolze2.png

> https://i.imgur.com/v2Mzyx5.png

Interesting I like them all. I converted your org file to latex and run
it with lualatex but the font used there does not correspond to all the
three screenshots.

Now I am not really acquainted with lualatex but with xelatex, I
converted QTMerryScript.otf to ttf and run it with xelatex. Nice. 

What are the other otf fonts you are using for these screenshots?

Thanks

Uwe

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

^ permalink raw reply	[relevance 1%]

* Re: A callygraphy notebook environment
  2022-01-30 20:37  1% ` Uwe Brauer
@ 2022-01-30 21:23  9%   ` Juan Manuel Macías
  2022-01-31 13:55  0%     ` Uwe Brauer
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-30 21:23 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode

Hi Uwe,

Thanks for testing the document.

Uwe Brauer writes:

> Interesting I like them all. I converted your org file to latex and run
> it with lualatex but the font used there does not correspond to all the
> three screenshots.

The default font for the environment 'mynotebook" is qtmerryscript
(shown in the third screenshot, if I remember correctly). I chose that
one because it is included in TeX live 2021.

> Now I am not really acquainted with lualatex but with xelatex, I
> converted QTMerryScript.otf to ttf and run it with xelatex. Nice.

But with XelaTeX the 'mynotebook' environment will not work, since it uses
a function in Lua to generate the grids in a notebook way.

> What are the other otf fonts you are using for these screenshots?

The document itself includes some links to download the other typefaces. Look
in the non-exportable section, named 'Conf', where it says "The different options
for the environment...". Anyway, I paste it here too:

- Vladimir Script :: https://fontzone.net/font-details/vladimir-script
- Anke Calligraphic :: https://fontzone.net/font-details/anke-calligraphic-fg
- Studio Script :: https://fontzone.net/download/studioscriptctt

(The third font was not in the screenshots).

Best regards,

Juan Manuel 



^ permalink raw reply	[relevance 9%]

* Re: A callygraphy notebook environment
  2022-01-30 21:23  9%   ` Juan Manuel Macías
@ 2022-01-31 13:55  0%     ` Uwe Brauer
  0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2022-01-31 13:55 UTC (permalink / raw)
  To: emacs-orgmode

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

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

> Hi Uwe,
> Thanks for testing the document.

> Uwe Brauer writes:

>> Interesting I like them all. I converted your org file to latex and run
>> it with lualatex but the font used there does not correspond to all the
>> three screenshots.

> The default font for the environment 'mynotebook" is qtmerryscript
> (shown in the third screenshot, if I remember correctly). I chose that
> one because it is included in TeX live 2021.

>> Now I am not really acquainted with lualatex but with xelatex, I
>> converted QTMerryScript.otf to ttf and run it with xelatex. Nice.

> But with XelaTeX the 'mynotebook' environment will not work, since it uses
> a function in Lua to generate the grids in a notebook way.

Right. That is true, at some point I have to learn lualatex, I am
afraid..

>> What are the other otf fonts you are using for these screenshots?

> The document itself includes some links to download the other typefaces. Look
> in the non-exportable section, named 'Conf', where it says "The different options
> for the environment...". Anyway, I paste it here too:

> - Vladimir Script :: https://fontzone.net/font-details/vladimir-script
> - Anke Calligraphic :: https://fontzone.net/font-details/anke-calligraphic-fg
> - Studio Script :: https://fontzone.net/download/studioscriptctt

Thanks, that was helpful.

Uwe 

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

^ permalink raw reply	[relevance 0%]

* Re: Org-syntax: Intra-word markup
  2022-01-29 13:05  9%                       ` Juan Manuel Macías
@ 2022-02-02 15:28  5%                         ` Max Nikulin
  2022-02-02 20:01  9%                           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-02-02 15:28 UTC (permalink / raw)
  To: emacs-orgmode

> Ihor Radchenko writes:
>> Keeping in mind the above analogy, note that export blocks do not have
>> fallbacks, while special blocks do (for example, see
>> https://github.com/alhassy/org-special-block-extras/)

Ihor, I am sorry, but I missed your point. That project provides some 
set of defined link+block pairs and some macros to define new 
links/pairs. I do not see relation to export snippets or blocks that are 
used when their content is not intended to be reusable.

>> Maybe we should introduce an equivalent of special blocks, but for
>> inline use? Or should we modify _both_ inline export snippets and export
>> blocks to allow fallback mechanism?

I suppose, it should be consistent to consider adjacent export blocks as 
alternatives and to allow "fallback" or "default" block. Again, similar 
to @@:...@@ snippets, block content should be parsed as Org markup.

On 29/01/2022 20:05, Juan Manuel Macías wrote:
> I find the idea of inline special blocks very interesting, but I think
> there are a couple of drawbacks: since special blocks support ATTR_X,
> how would that be implemented in the inline version? The most obvious
> thing I can think of is to mimic inline code blocks:
> 
> my_special_block[attributes list]{content}

ATTR_X attributes are supported for links as well, see
info "(org) Links in HTML export"
https://orgmode.org/manual/Links-in-HTML-export.html
However it is rather verbose, may have problems with LaTeX, and I am 
unsure if they can be accessed from export link handlers

Actually I do not like src_something[...]{...} syntax since there is no 
clear mark (such as "\") at the beginning that it is a special construct.

> In any case, for things like that, aren't links and macros enough?

Ad hoc code for particular backends (and discussed fallback for other 
backends) is a bit different thing. It may be used in macros, but macros 
can not replace it. Moreover @@:...@@ construct proposed by Tom would 
allow e.g.
    [[https://orgmode.org][@@:*inter*@@@@:/word/@@]]
to be half-word bold and half-word italics without invisible zero width 
spaces and filters to remove them.



^ permalink raw reply	[relevance 5%]

* Re: [PATCH] Intra-word markup: \relax
  2022-01-28 13:13  9%   ` Juan Manuel Macías
@ 2022-02-02 15:42  5%     ` Max Nikulin
  0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-02-02 15:42 UTC (permalink / raw)
  To: emacs-orgmode

On 28/01/2022 20:13, Juan Manuel Macías wrote:
> Max Nikulin writes:
> 
>> I have an idea how to implement *intra*/word/ markup with minimal
>> change of Org syntax. At first I had a hope that it is enough to
>> introduce \relax entity that expands to empty string, but it does not
>> work for second part of words: *intra*\relax{}/word/ is exported to
>>      <b>intra</b>/word/.
>> So it is necessary to support consuming spaces after such entity
>> similar to TeX commands:
>>      *intra*\relax /word/
>> In Org "a\_      b" already behaves in the same way.
> 
> Maxim, I find the idea of \relax entity interesting. The only (minor)
> drawback I find (in normal use, I mean) is the verbosity it adds.

"Relax" is just a name known to TeX users. Certainly another shorter 
word may be used instead. I am just lazy enough to look through HTML 
named entities and LaTeX command to avoid conflicts and thus behavior 
unexpected to some users.

> In my case, I have already given up on the problem of marks inside words
> :-(. My personal opinion: I think that, unless a completely
> 'revolutionary' solution emerges, it is better to leave the matter as it
> is, and consider this a feature of Org rather than a bug. I suspect that
> a single solution could not satisfy all tastes or all possible
> scenarios, so maybe it would be nice to put a list of solutions
> (including this one and also the zero space thing, and others that have
> arisen or may arise) somewhere (perhaps in the manual?).

A day before I posted my current summary why export snippets and macros 
do not help with intra-word markup (before I expected that they can), 
only custom links is a workaround (with some limitations, as usual):

[RFC] Creole-style / Support for **emphasis**__within__**a word**
Tue, 25 Jan 2022 23:27:50 +0700.
https://list.orgmode.org/ssp8e7$ah2$1@ciao.gmane.io/

But at that moment I forgot about entities, Another topic served as a 
reminder, and I spent some time experimenting with them.



^ permalink raw reply	[relevance 5%]

* Re: Org-syntax: Intra-word markup
  2022-02-02 15:28  5%                         ` Max Nikulin
@ 2022-02-02 20:01  9%                           ` Juan Manuel Macías
  2022-02-03 12:10  4%                             ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-02 20:01 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

Max Nikulin writes:

> ATTR_X attributes are supported for links as well, see
> info "(org) Links in HTML export"
> https://orgmode.org/manual/Links-in-HTML-export.html
> However it is rather verbose, may have problems with LaTeX, and I am
> unsure if they can be accessed from export link handlers

Yes, I know. I use a lot in my blogs constructions of this type:

#+ATTR_HTML: :target _blank
some link...

But, as far as I know, its use is line-oriented. I mean, you can't use
multiple ATTR_X constructs inside a paragraph and for different links
inside the paragraph.

As for links and their multiple possible or future uses (I say *uses*
and never *abuses*: it's a tool, it's there to be used, and it works
great), of course I see them more as a resource ---and quite powerful
and versatile, by the way. --- that a matter of syntax. But the thing is
that for me Org is, in addition to a syntax, above all a set of
coherently assembled resources to prepare my documents and take my
notes, organize my work and a lot of other things.

Best regards,

Juan Manuel 



^ permalink raw reply	[relevance 9%]

* Re: Org-syntax: Intra-word markup
  2022-02-02 20:01  9%                           ` Juan Manuel Macías
@ 2022-02-03 12:10  4%                             ` Max Nikulin
  0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-02-03 12:10 UTC (permalink / raw)
  To: emacs-orgmode

On 03/02/2022 03:01, Juan Manuel Macías wrote:
> Max Nikulin writes:
> 
>> ATTR_X attributes are supported for links as well, see
>> info "(org) Links in HTML export"
>> https://orgmode.org/manual/Links-in-HTML-export.html
>> However it is rather verbose, may have problems with LaTeX, and I am
>> unsure if they can be accessed from export link handlers
> 
> Yes, I know. I use a lot in my blogs constructions of this type:
> 
> #+ATTR_HTML: :target _blank
> some link...

I just have realized that example in the manual does not work. I will 
start a new thread. Attributes are assigned to paragraph, not to the link:

#+ATTR_HTML: :title The Org mode homepage :style color:red;
[[https://orgmode.org]]

<p title="The Org mode homepage" style="color:red;">
<a href="https://orgmode.org" title="The Org mode homepage" 
style="color:red;">https://orgmode.org</a>
</p>

> But, as far as I know, its use is line-oriented. I mean, you can't use
> multiple ATTR_X constructs inside a paragraph and for different links
> inside the paragraph.

Thank you, I confused issues related to export when keywords and export 
blocks are used. For some reason I believed that affiliated keywords 
have a dedicated section in https://orgmode.org/worg/dev/org-syntax.html 
because they can be applied to inline objects, but you are right, they 
set property for next block-level element.

Attributes from several lines are combined however.

The following snippets illustrates bugs in LaTeX exporter that I 
remember from an earlier discussion:

---- >8 ----

This is a single paragraph in LaTeX export, but 3 HTML paragraphs.
First link (with =rel= attribute) is to
#+attr_html: :rel nofollow :title Org Mode web site
[[https://orgmode.org/][Org Mode]].
Another one is to
#+attr_html: :rel noopener
#+attr_html: :title GNU web site
[[https://www.gnu.org/][GNU]]. Both links have =title= HTML attributes.

This is single paragraph in HTML
@@odt:@@
but 2 paragraphs in LaTeX.

---- 8< ----

This is a single paragraph in \LaTeX{} export, but 3 HTML paragraphs.
First link (with \texttt{rel} attribute) is to
\href{https://orgmode.org/}{Org Mode}.
Another one is to
\href{https://www.gnu.org/}{GNU}. Both links have \texttt{title} HTML 
attributes.

This is single paragraph in HTML

but 2 paragraphs in \LaTeX{}.

---- >8 ----

<p>
This is a single paragraph in LaTeX export, but 3 HTML paragraphs.
First link (with <code>rel</code> attribute) is to
</p>
<p rel="nofollow" title="Org Mode web site">
<a href="https://orgmode.org/" rel="nofollow" title="Org Mode web 
site">Org Mode</a>.
Another one is to
</p>
<p title="GNU web site" rel="noopener">
<a href="https://www.gnu.org/" title="GNU web site" 
rel="noopener">GNU</a>. Both links have <code>title</code> HTML attributes.
</p>

<p>
This is single paragraph in HTML

but 2 paragraphs in LaTeX.</p>



^ permalink raw reply	[relevance 4%]

* [PATCH] org-manual.org: update and add info for arbitrary :float values
@ 2022-02-11 20:37  8% Juan Manuel Macías
  2022-02-13 21:18  6% ` Nicolas Goaziou
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-11 20:37 UTC (permalink / raw)
  To: orgmode

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

Hi all,

From the commit:

e0bc2b37f :: lisp/ox-latex.el: Allow arbitrary float environments

The `t' option for `:float' in tables and images is no longer valid.
That is, something like

#+ATTR_LaTeX: :float t
[[file:foo.jpg]]

would create in LaTeX export:

\begin{t}
\centering
\includegraphics[width=.9\linewidth]{foo.jpg}
\end{t}

I am attaching a patch to update those changes to the Manual.

Best regards,

Juan Manuel


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-doc-org-manual.org-add-arbitrary-float-values.patch --]
[-- Type: text/x-patch, Size: 1932 bytes --]

From 03aacd306355741f67533325dd6dbd8c5a472ec0 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 11 Feb 2022 21:18:16 +0100
Subject: [PATCH] doc/org-manual.org: add arbitrary :float values

* Tables in LaTeX export: remove `t' value
* Images in LaTeX export: remove `t' value
---
 doc/org-manual.org | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b8c61fddd..4c6fcf8db 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13572,7 +13572,11 @@ include:
 
   The table environments by default are not floats in LaTeX.  To make
   them floating objects use =:float= with one of the following
-  options: =sideways=, =multicolumn=, =t=, and =nil=.
+  options: =sideways= (for a =sidewaystable= environment),
+  =multicolumn= (to span the table across multiple columns of a page
+  in a =table*= environment) and =nil=. In addition to these three
+  values, =:float= can pass through any arbitrary value, for example a
+  user-defined float type with the =float= LaTeX package.
 
   LaTeX floats can also have additional layout =:placement=
   attributes.  These are the usual =[h t b p ! H]= permissions
@@ -13684,11 +13688,6 @@ export back-end wraps the picture in a floating =figure= environment.
 To float an image without specifying a caption, set the =:float=
 attribute to one of the following:
 
-- =t= ::
-
-  For a standard =figure= environment; used by default whenever an
-  image has a caption.
-
 - =multicolumn= ::
 
   To span the image across multiple columns of a page; the back-end
@@ -13708,6 +13707,11 @@ attribute to one of the following:
 
   To avoid a =:float= even if using a caption.
 
+- Any arbitrary value ::
+
+ For example, a user-defined float type with the =float= LaTeX package.
+
+
 Use the =placement= attribute to modify a floating environment's
 placement.
 
-- 
2.35.0


^ permalink raw reply related	[relevance 8%]

* Re: [PATCH] org-manual.org: update and add info for arbitrary :float values
  2022-02-11 20:37  8% [PATCH] org-manual.org: update and add info for arbitrary :float values Juan Manuel Macías
@ 2022-02-13 21:18  6% ` Nicolas Goaziou
  2022-02-13 22:21 10%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2022-02-13 21:18 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Hello,

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

> Hi all,
>
> From the commit:
>
> e0bc2b37f :: lisp/ox-latex.el: Allow arbitrary float environments
>
> The `t' option for `:float' in tables and images is no longer valid.
> That is, something like
>
> #+ATTR_LaTeX: :float t
> [[file:foo.jpg]]
>
> would create in LaTeX export:
>
> \begin{t}
> \centering
> \includegraphics[width=.9\linewidth]{foo.jpg}
> \end{t}
>
> I am attaching a patch to update those changes to the Manual.

Thanks. Note you need to add two spaces between sentences.

However, isn't it a bug? Shouldn't t value default to "figure"
environment, if only for the sake of backward compatibility?

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[relevance 6%]

* Re: [PATCH] org-manual.org: update and add info for arbitrary :float values
  2022-02-13 21:18  6% ` Nicolas Goaziou
@ 2022-02-13 22:21 10%   ` Juan Manuel Macías
  2022-02-15 13:24  6%     ` Nicolas Goaziou
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-13 22:21 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: orgmode

Hi Nicolas,

Nicolas Goaziou writes:

> Thanks. Note you need to add two spaces between sentences.

Ah, sorry, I hadn't noticed that :-). The thing is that I have in my
~/.emacs `sentence-end-double-space' set to nil.

> However, isn't it a bug? Shouldn't t value default to "figure"
> environment, if only for the sake of backward compatibility?

I think you're right. t value should be figure and table, I agree. Would
it be appropriate to add these two lines:

In org-latex--inline-image:

((string= float "t") 'figure)

And in org-latex--decorate-table

((string= float "t") "table")

?

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: Root heading when exporting sub-trees
  @ 2022-02-15 12:36 10% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-15 12:36 UTC (permalink / raw)
  To: Michael Dauer; +Cc: orgmode

Hi Michael,

Michael Dauer writes:

> When I export a subtree I normally want to produce a document for the
> topic of the subtree. So I would expect that the contents of the
> subtree would be exported with the heading as title (and maybe file
> name) and the children promoted to level 1.
>
> What I receive is something like this:
> Title: Title of all topics
> 1. Topic
> 1.1
> 1.2
> 1.2.1
> 1.2.3
> 1.3
>
> The whole first level of this outline is pointless.
>
> What is the best way to change this behavior? I mean in
> configuration/patching not by putting the same export properties
> everywhere. But identifying the relevant export properties would be of
> help of course.

You can set specific export properties for a given subtree, for example:

* Subtree
  :PROPERTIES:
  :EXPORT_OPTIONS: options list
  :EXPORT_TITLE: Another title
  :EXPORT_FILE_NAME: another file name
  :END:

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [PATCH] org-manual.org: update and add info for arbitrary :float values
  2022-02-13 22:21 10%   ` Juan Manuel Macías
@ 2022-02-15 13:24  6%     ` Nicolas Goaziou
  2022-02-16 19:52  8%       ` [PATCH] ox-latex.el: Add a `t' value for `:float' in tables and figures (was: update and add info for arbitrary :float values) Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2022-02-15 13:24 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Hello,

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

> Ah, sorry, I hadn't noticed that :-). The thing is that I have in my
> ~/.emacs `sentence-end-double-space' set to nil.

Yes, .dir-locals.el files contains (sentence-end-double-space . t).
Somehow, you are not evaluating it.

>> However, isn't it a bug? Shouldn't t value default to "figure"
>> environment, if only for the sake of backward compatibility?
>
> I think you're right. t value should be figure and table, I agree. Would
> it be appropriate to add these two lines:
>
> In org-latex--inline-image:
>
> ((string= float "t") 'figure)
>
> And in org-latex--decorate-table
>
> ((string= float "t") "table")

I think so.

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[relevance 6%]

* Re: table format during html export
  @ 2022-02-15 22:16 10% ` Juan Manuel Macías
  2022-02-16 15:57  6%   ` Leo Butler
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-15 22:16 UTC (permalink / raw)
  To: Leo Butler; +Cc: orgmode

Hi Leo,

Leo Butler writes:

> Hello,
>
> I have some tables like
>
> | a | b |
> | c | d |
>
> I would like to have this export (in html) to something like
>
> | a  b |
> | c  d |
>
> i.e., add a vertical bar on the extreme left and right.
>
> I have searched the org manual and online and I can't find a
> solution.
>
> TIA,
> Leo
>

You can modify the attributes for a certain table, for example like this:

#+ATTR_HTML: :border 2 :cellspacing 0 :cellpadding 6 :rules none :frame vsides
| a | b |
| c | d |

For all tables, you can apply a value to
`org-html-table-default-attributes', locally or globally:

#+begin_src emacs-lisp
(setq org-html-table-default-attributes
  '(:border "2" :cellspacing "0" :cellpadding "6" :rules "none" :frame "vsides"))
#+end_src

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: table format during html export
  2022-02-15 22:16 10% ` Juan Manuel Macías
@ 2022-02-16 15:57  6%   ` Leo Butler
  0 siblings, 0 replies; 200+ results
From: Leo Butler @ 2022-02-16 15:57 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> Hi Leo,
>
> Leo Butler writes:
>
>> Hello,
>>
>> I have some tables like
>>
>> | a | b |
>> | c | d |
>>
>> I would like to have this export (in html) to something like
>>
>> | a  b |
>> | c  d |
>>
>> i.e., add a vertical bar on the extreme left and right.
>>
>> I have searched the org manual and online and I can't find a
>> solution.
>>
>> TIA,
>> Leo
>>
>
> You can modify the attributes for a certain table, for example like this:
>
> #+ATTR_HTML: :border 2 :cellspacing 0 :cellpadding 6 :rules none :frame vsides
> | a | b |
> | c | d |
>
> For all tables, you can apply a value to
> `org-html-table-default-attributes', locally or globally:
>
> #+begin_src emacs-lisp
> (setq org-html-table-default-attributes
>   '(:border "2" :cellspacing "0" :cellpadding "6" :rules "none" :frame "vsides"))
> #+end_src

Thank you! That did exactly what I wanted.

Leo


^ permalink raw reply	[relevance 6%]

* Re: [PATCH] ox-latex.el: Add a `t' value for `:float' in tables and figures (was: update and add info for arbitrary :float values)
  2022-02-15 13:24  6%     ` Nicolas Goaziou
@ 2022-02-16 19:52  8%       ` Juan Manuel Macías
  2022-02-22 19:14  6%         ` [PATCH] ox-latex.el: Add a `t' value for `:float' in tables and figures Nicolas Goaziou
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-16 19:52 UTC (permalink / raw)
  To: orgmode; +Cc: Nicolas Goaziou

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

Hi,

I am attaching an updated version of the patch, which retrieves the
`t' value for `:float' in tables and figures. The necessary information in
the Manual is also updated.

Best regards,

Juan Manuel 

Nicolas Goaziou writes:

> Hello,
>
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Ah, sorry, I hadn't noticed that :-). The thing is that I have in my
>> ~/.emacs `sentence-end-double-space' set to nil.
>
> Yes, .dir-locals.el files contains (sentence-end-double-space . t).
> Somehow, you are not evaluating it.
>
>>> However, isn't it a bug? Shouldn't t value default to "figure"
>>> environment, if only for the sake of backward compatibility?
>>
>> I think you're right. t value should be figure and table, I agree. Would
>> it be appropriate to add these two lines:
>>
>> In org-latex--inline-image:
>>
>> ((string= float "t") 'figure)
>>
>> And in org-latex--decorate-table
>>
>> ((string= float "t") "table")
>
> I think so.
>
> Regards,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Add-a-t-value-for-float-in-tables-a.patch --]
[-- Type: text/x-patch, Size: 2955 bytes --]

From b00b1d30d66d0932d4becb3c74fe3c3837dbdec1 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Wed, 16 Feb 2022 20:27:38 +0100
Subject: [PATCH] lisp/ox-latex.el: Add a `t' value for `:float' in tables and
 figures

* org-latex--inline-image: default `figure' environment
* org-latex--decorate-table: default table environment
* doc/org-manual.org (Tables in LaTeX export): add `t' and arbitrary
`:float' values
* doc/org-manual.org (Images in LaTeX export): add `t' and arbitrary
`:float' values
---
 doc/org-manual.org | 15 ++++++++++++---
 lisp/ox-latex.el   |  2 ++
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b8c61fddd..d58f80523 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13572,7 +13572,12 @@ include:
 
   The table environments by default are not floats in LaTeX.  To make
   them floating objects use =:float= with one of the following
-  options: =sideways=, =multicolumn=, =t=, and =nil=.
+  options: =t= (for a default =table= environment), =sideways= (for a
+  =sidewaystable= environment), =multicolumn= (to span the table
+  across multiple columns of a page in a =table*= environment) and
+  =nil=.  In addition to these three values, =:float= can pass through
+  any arbitrary value, for example a user-defined float type with the
+  =float= LaTeX package.
 
   LaTeX floats can also have additional layout =:placement=
   attributes.  These are the usual =[h t b p ! H]= permissions
@@ -13686,8 +13691,7 @@ attribute to one of the following:
 
 - =t= ::
 
-  For a standard =figure= environment; used by default whenever an
-  image has a caption.
+For a default =figure= environment. 
 
 - =multicolumn= ::
 
@@ -13708,6 +13712,11 @@ attribute to one of the following:
 
   To avoid a =:float= even if using a caption.
 
+- Any arbitrary value ::
+
+ For example, a user-defined float type with the =float= LaTeX package.
+
+
 Use the =placement= attribute to modify a floating environment's
 placement.
 
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 5dda9b3ab..0edba9e52 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2414,6 +2414,7 @@ used as a communication channel."
 		  (cond ((string= float "wrap") 'wrap)
 			((string= float "sideways") 'sideways)
 			((string= float "multicolumn") 'multicolumn)
+                        ((string= float "t") 'figure)
 			((and (plist-member attr :float) (not float)) 'nonfloat)
                         (float float)
 			((or (org-element-property :caption parent)
@@ -3269,6 +3270,7 @@ Return new environment, as a string."
 	    (cond ((and (not float) (plist-member attributes :float)) nil)
 		  ((member float '("sidewaystable" "sideways")) "sidewaystable")
 		  ((equal float "multicolumn") "table*")
+                  ((string= float "t") "table")
                   (float float)
 		  ((org-string-nw-p caption) "table")
 		  (t nil))))
-- 
2.35.0


^ permalink raw reply related	[relevance 8%]

* Re: Question Regarding Creating HTML Style Buttons With Org Mode
  @ 2022-02-17 22:10 10% ` Juan Manuel Macías
  2022-02-18 19:59  6%   ` Samuel Banya
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-17 22:10 UTC (permalink / raw)
  To: Samuel Banya; +Cc: orgmode

Hi Samuel:

Samuel Banya writes:

> Is it possible to create HTML style buttons using Org Mode itself?

One possibility is to use a custom link. For example:

#+begin_src emacs-lisp
  (org-link-set-parameters "button"
			   :face '(:foreground "green" :underline t)
			   :export (lambda (path desc backend)
				     (when (eq backend 'html)
				       (format "<form><button class=\"mybutton\" formaction=\"%s\">%s</button></form>" path desc))))
#+end_src

#+HTML_HEAD: <style> .mybutton{background-color:#4CAF50;border:none;color:white;padding:15px32px;text-align:center;text-decoration:none;display:inline-block;font-size:18px;margin:4px2px;cursor:pointer;</style>

[[button:some target][This is a button]]

NB: I have borrowed the style from here: https://www.w3schools.com/csS/css3_buttons.asp

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Pandoc and nested emhases
@ 2022-02-18  0:47  8% Juan Manuel Macías
  2022-02-18 12:06  4% ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-18  0:47 UTC (permalink / raw)
  To: orgmode

Hi all,

Sorry in advance if this may sound too trivial, imprecise or naive: it's
just for my curiosity, as I've recently been doing some tests with Pandoc
and I've seen something that has caught my attention.

It is known that LaTeX-style nested emphases of the same category are
not possible in Org. For example, the following string does not export
to LaTeX as expected:

#+begin_src org :results latex replace
/lorem /ipsum/ dolor/
#+end_src

#+RESULTS:
#+begin_export latex
\emph{lorem /ipsum} dolor/
#+end_export

Otherwise, if you export to LaTeX with pandoc (v. 2.14.2), the result is
(to my surprise) correct:

#+begin_src sh :results latex
str="/lorem /ipsum/ dolor/" 
pandoc -f org -t latex <<< $str
#+end_src

#+RESULTS:
#+begin_export latex
\emph{lorem \emph{ipsum} dolor}
#+end_export

If memory serves me, I think this was not possible before with Pandoc
(neither from Org nor from Markdown, but I insist that I don't know if
my memory is failing me too much :-)).

Anyway, I wonder if it would be possible for Org to somehow implement
some Pandoc procedure to be able to export nested emphases of the same
category.

Another (more abstract) doubt that arises, although I am not an expert
in matters of grammar and specifications. If nested emphases of the same
category are not possible in Org, should this be understood as a bug or
a feature? What implication does it have if a external parser, like
Pandoc, parses them just "fine"?

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 8%]

* Re: Pandoc and nested emhases
  2022-02-18  0:47  8% Pandoc and nested emhases Juan Manuel Macías
@ 2022-02-18 12:06  4% ` Max Nikulin
  2022-02-18 12:31 10%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-02-18 12:06 UTC (permalink / raw)
  To: emacs-orgmode

On 18/02/2022 07:47, Juan Manuel Macías wrote:
> 
> Otherwise, if you export to LaTeX with pandoc (v. 2.14.2), the result is
> (to my surprise) correct:
> 
> str="/lorem /ipsum/ dolor/"
> pandoc -f org -t latex <<< $str
> \emph{lorem \emph{ipsum} dolor}

2.5-3build2 from Ubuntu-20.04 works in the same way.

I like such behavior:

echo "/lorem =ip/ sum= dolor/" | pandoc -f org -t latex
\emph{lorem \texttt{ip/\ sum} dolor}

I know at least one more persons who will be happy as well:
https://list.orgmode.org/87pmtqp79s.fsf@web.de/T/#u 
mid:87pmtqp79s.fsf@web.de
(tracked as a confirmed bug at https://updates.orgmode.org/)

printf '/lorem\nipsum [[https://orgmode.org/,service][dolor]] ipsum/\n' 
| pandoc -f org -t latex
\emph{lorem ipsum \href{https://orgmode.org/,service}{dolor} ipsum}

> Another (more abstract) doubt that arises, although I am not an expert
> in matters of grammar and specifications. If nested emphases of the same
> category are not possible in Org, should this be understood as a bug or
> a feature? What implication does it have if a external parser, like
> Pandoc, parses them just "fine"?

Nicolas Goaziou explicitly stated that current behavior is correct, see 
"[Patch] to correctly sort the items with emphasis marks in a list". 
Tue, 20 Apr 2021 22:37:31 +0200. mid:874kg0ae0k.fsf@nicolasgoaziou.fr
https://list.orgmode.org/874kg0ae0k.fsf@nicolasgoaziou.fr/

Nicolas confirmed it when I posted a similar example later in the 
following discussion:

Ihor Radchenko. c47b535bb origin/main org-element: Remove dependency on 
‘org-emphasis-regexp-components’
Thu, 18 Nov 2021 20:25:33 +0800. mid:87tug93b2a.fsf@localhost
https://list.orgmode.org/87tug93b2a.fsf@localhost/
> My intuition says that the current parser behaviour is not correct. It
> would make more sense to prioritise link over italics. However, it would
> require a major change in the parser - instead of a single pass, the
> parser may parse different types of objects sequentially.

Nicolas Goaziou. c47b535bb origin/main org-element: Remove dependency on 
‘org-emphasis-regexp-components’
Thu, 18 Nov 2021 13:35:19 +0100. mid:87y25l8wvs.fsf@nicolasgoaziou.fr
https://list.orgmode.org/87y25l8wvs.fsf@nicolasgoaziou.fr/
> I disagree. Priority should be given to the first object being started.
> This is, IMO, the only sane way to handle syntax.

And once more in response to my message:

Nicolas Goaziou. org parser and priorities of inline elements.
Sat, 27 Nov 2021 20:02:31 +0100. mid:87mtlppgl4.fsf@nicolasgoaziou.fr
https://list.orgmode.org/87mtlppgl4.fsf@nicolasgoaziou.fr/
> I don't see any incentive to change the order objects are parsed, once
> you know how Org does it. This is just a red herring. What is useful,
> however, is to fontify them the way Org sees them.

So formally this feature of pandoc is a bug (due to different kind of 
parser). It is the reason why a corpus of tests should exist in a format 
that can be easily imported from various programming languages.



^ permalink raw reply	[relevance 4%]

* Re: Pandoc and nested emhases
  2022-02-18 12:06  4% ` Max Nikulin
@ 2022-02-18 12:31 10%   ` Juan Manuel Macías
  2022-02-24 12:50  5%     ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-18 12:31 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

Hi Maxim,

Max Nikulin writes:

> So formally this feature of pandoc is a bug (due to different kind of
> parser). It is the reason why a corpus of tests should exist in a
> format that can be easily imported from various programming languages.

Your conclusions seem logical to me. It may sound a bit surrealistic to
think that Pandoc is doing it wrong precisely for doing it "right", but...
if from Org's point of view this is not something specified in its
syntax, then here Pandoc makes a mistake parsing Org's syntax. All this
is very curious, indeed. I confess that before I did not see the need for
those corpus of tests very clearly, but this case has opened my mind.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: Question Regarding Creating HTML Style Buttons With Org Mode
  2022-02-17 22:10 10% ` Juan Manuel Macías
@ 2022-02-18 19:59  6%   ` Samuel Banya
  2022-02-18 20:04  0%     ` Samuel Banya
  2022-02-18 20:38 10%     ` Juan Manuel Macías
  0 siblings, 2 replies; 200+ results
From: Samuel Banya @ 2022-02-18 19:59 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Charles Berry

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

I tried to use this idea, but I'm not sure how to set the 'target' in your example:
[[button:some target][This is a button]]

For example, I tried this:
[[button:http://www.sambanya.com/artgallery.html][Art Gallery Page Link]]

But received this error:
user-error: Unable to resolve link: "button:http://www.sambanya.com/artgallery.html"

Thanks,

Sam

On Thu, Feb 17, 2022, at 5:10 PM, Juan Manuel Macías wrote:
> Hi Samuel:
> 
> Samuel Banya writes:
> 
> > Is it possible to create HTML style buttons using Org Mode itself?
> 
> One possibility is to use a custom link. For example:
> 
> #+begin_src emacs-lisp
>   (org-link-set-parameters "button"
>    :face '(:foreground "green" :underline t)
>    :export (lambda (path desc backend)
>      (when (eq backend 'html)
>        (format "<form><button class=\"mybutton\" formaction=\"%s\">%s</button></form>" path desc))))
> #+end_src
> 
> #+HTML_HEAD: <style> .mybutton{background-color:#4CAF50;border:none;color:white;padding:15px32px;text-align:center;text-decoration:none;display:inline-block;font-size:18px;margin:4px2px;cursor:pointer;</style>
> 
> [[button:some target][This is a button]]
> 
> NB: I have borrowed the style from here: https://www.w3schools.com/csS/css3_buttons.asp
> 
> Best regards,
> 
> Juan Manuel 
> 

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

^ permalink raw reply	[relevance 6%]

* Re: Question Regarding Creating HTML Style Buttons With Org Mode
  2022-02-18 19:59  6%   ` Samuel Banya
@ 2022-02-18 20:04  0%     ` Samuel Banya
  2022-02-18 20:38 10%     ` Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: Samuel Banya @ 2022-02-18 20:04 UTC (permalink / raw)
  To: Charles Berry

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

Also, how could you possible add an 'id' or 'class' attribute to an existing lOrg mode style hyperink?

I ask because I like your approach to just modify the stylesheet, but am unaware of how to actually utilize HTML's concept or 'id' or 'class' in an Org doc itself when using basic Org mode style hyperlinks [[link address][link description]]

Also, I ask because I found a similar video to just style the hyperlink in a similar fashion but would need to somehow assign a class or id value to the HTML element that's exported from the hyperlink itself:
Styling HTML Anchor Tag (Link) To Look Like A Button | CSS Tutorial (https://www.youtube.com/watch?v=p5nogm7ul6A) 

Thanks,

Sam

On Fri, Feb 18, 2022, at 2:59 PM, Samuel Banya wrote:
> I tried to use this idea, but I'm not sure how to set the 'target' in your example:
> [[button:some target][This is a button]]
> 
> For example, I tried this:
> [[button:http://www.sambanya.com/artgallery.html][Art Gallery Page Link]]
> 
> But received this error:
> user-error: Unable to resolve link: "button:http://www.sambanya.com/artgallery.html"
> 
> Thanks,
> 
> Sam
> 
> On Thu, Feb 17, 2022, at 5:10 PM, Juan Manuel Macías wrote:
>> Hi Samuel:
>> 
>> Samuel Banya writes:
>> 
>> > Is it possible to create HTML style buttons using Org Mode itself?
>> 
>> One possibility is to use a custom link. For example:
>> 
>> #+begin_src emacs-lisp
>>   (org-link-set-parameters "button"
>>    :face '(:foreground "green" :underline t)
>>    :export (lambda (path desc backend)
>>      (when (eq backend 'html)
>>        (format "<form><button class=\"mybutton\" formaction=\"%s\">%s</button></form>" path desc))))
>> #+end_src
>> 
>> #+HTML_HEAD: <style> .mybutton{background-color:#4CAF50;border:none;color:white;padding:15px32px;text-align:center;text-decoration:none;display:inline-block;font-size:18px;margin:4px2px;cursor:pointer;</style>
>> 
>> [[button:some target][This is a button]]
>> 
>> NB: I have borrowed the style from here: https://www.w3schools.com/csS/css3_buttons.asp
>> 
>> Best regards,
>> 
>> Juan Manuel 
>> 
> 

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

^ permalink raw reply	[relevance 0%]

* Re: Question Regarding Creating HTML Style Buttons With Org Mode
  2022-02-18 19:59  6%   ` Samuel Banya
  2022-02-18 20:04  0%     ` Samuel Banya
@ 2022-02-18 20:38 10%     ` Juan Manuel Macías
  2022-02-18 20:51 12%       ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-18 20:38 UTC (permalink / raw)
  To: Samuel Banya; +Cc: orgmode

Samuel Banya writes:

> I tried to use this idea, but I'm not sure how to set the 'target' in
> your example:
> [[button:some target][This is a button]]
>
> For example, I tried this:
> [[button:http://www.sambanya.com/artgallery.html][Art Gallery Page
> Link]]
>
> But received this error:
> user-error: Unable to resolve link:
> "button:http://www.sambanya.com/artgallery.html"

Hi Samuel,

It's strange... I have tried your link, and it works fine for me. I have
made this video capture:

https://cloud.disroot.org/s/SaHR7jenTWxFWZt

If you evaluate the `org-ling-set-parameters' expression that I gave
you, you should get when exporting to html:

<p>
<form><button class="mybutton" formaction="http://www.sambanya.com/artgallery.html">Art Gallery Page Link</button></form>
</p>

What version of org are you using?

(I don't have much knowledge of html or css, in any case. Just for the
basics).

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: Question Regarding Creating HTML Style Buttons With Org Mode
  2022-02-18 20:38 10%     ` Juan Manuel Macías
@ 2022-02-18 20:51 12%       ` Juan Manuel Macías
  2022-02-19  1:02  6%         ` Samuel Banya
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-18 20:51 UTC (permalink / raw)
  To: Samuel Banya; +Cc: orgmode

Juan Manuel Macías writes:

> If you evaluate the `org-ling-set-parameters' expression that I gave
> you, you should get when exporting to html:
>
> <p>
> <form><button class="mybutton" formaction="http://www.sambanya.com/artgallery.html">Art Gallery Page Link</button></form>
> </p>

P.S.: I forgot to tell you that if you want to visit the link also from the
Org file itself, you must add this parameter to org-link-set-parameters:

:follow (lambda (path) (browse-url path))

Best regards,

jm


^ permalink raw reply	[relevance 12%]

* Re: Question Regarding Creating HTML Style Buttons With Org Mode
  2022-02-18 20:51 12%       ` Juan Manuel Macías
@ 2022-02-19  1:02  6%         ` Samuel Banya
  2022-02-19  9:41  8%           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Samuel Banya @ 2022-02-19  1:02 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Charles Berry

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

To clarify, did you evaluate that code block on the org mode docs itself?

I ask because if I try to evaluate it, aka 'C-c C-c' on the '#begin_src' block, nothing happens.

And after I export the Org Doc to HTML, it still gives me that same error as before.

On Fri, Feb 18, 2022, at 3:51 PM, Juan Manuel Macías wrote:
> Juan Manuel Macías writes:
> 
> > If you evaluate the `org-ling-set-parameters' expression that I gave
> > you, you should get when exporting to html:
> >
> > <p>
> > <form><button class="mybutton" formaction="http://www.sambanya.com/artgallery.html">Art Gallery Page Link</button></form>
> > </p>
> 
> P.S.: I forgot to tell you that if you want to visit the link also from the
> Org file itself, you must add this parameter to org-link-set-parameters:
> 
> :follow (lambda (path) (browse-url path))
> 
> Best regards,
> 
> jm
> 

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

^ permalink raw reply	[relevance 6%]

* Re: Question Regarding Creating HTML Style Buttons With Org Mode
  2022-02-19  1:02  6%         ` Samuel Banya
@ 2022-02-19  9:41  8%           ` Juan Manuel Macías
  2022-02-19  9:51 12%             ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-19  9:41 UTC (permalink / raw)
  To: Samuel Banya; +Cc: orgmode

Samuel Banya writes:

> To clarify, did you evaluate that code block on the org mode docs
> itself?

The code must be evaluated *before* using that new type of link, or saved
to your ~/.emacs. You can simply evaluate it in your `scratch' buffer:

  (org-link-set-parameters "button"
			   :face '(:foreground "green4" :underline t)
			   :follow (lambda (path) (browse-url path))
			   :export (lambda (path desc backend)
				     (when (eq backend 'html)
				       (format "<form><button class=\"mybutton\" formaction=\"%s\">%s</button></form>" path desc))))

If you want to pass the class or id 'manually' to each link, and thus
have more control, you can evaluate this other version, where the class
or id would be added at the end of the link description, after (for
example) "!style":

  (org-link-set-parameters "button"
			   :face '(:foreground "green4" :underline t)
			   :follow (lambda (path) (browse-url path))
			   :export (lambda (path desc backend)
				     (when (eq backend 'html)
				       (let* ((style (if (string-match "\\(!style .+\\)" desc)
							 (match-string 1 desc)
						       ""))
					      (desc (replace-regexp-in-string style "" desc)))
					 (format "<form><button %s formaction=\"%s\">%s</button></form>" style path desc)))))

Example:

[[button:http://www.sambanya.com/artgallery.html][Art Gallery Page Link !style class="mybutton"]]

== HTML ==>

<p>
<form><button !style class="mybutton" formaction="http://www.sambanya.com/artgallery.html">Art Gallery Page Link </button></form>
</p>

> I ask because if I try to evaluate it, aka 'C-c C-c' on the
> '#begin_src' block, nothing happens.

When you evaluate the code and add the new link type 'button', does it
appear in your document with the face defined for that link: green,
underlined? Have you tried testing it on a clean Emacs/Org?

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: Question Regarding Creating HTML Style Buttons With Org Mode
  2022-02-19  9:41  8%           ` Juan Manuel Macías
@ 2022-02-19  9:51 12%             ` Juan Manuel Macías
  2022-02-21  0:38  6%               ` Samuel Banya
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-19  9:51 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías writes:

> If you want to pass the class or id 'manually' to each link, and thus
> have more control, you can evaluate this other version, where the class
> or id would be added at the end of the link description, after (for
> example) "!style":

PS: Sorry, this is the correct code:

  (org-link-set-parameters "button"
			   :face '(:foreground "green4" :underline t)
			   :follow (lambda (path) (browse-url path))
			   :export (lambda (path desc backend)
				     (when (eq backend 'html)
				       (let ((style (if (string-match "\\(!style\\)\\(.+\\)" desc)
							 (match-string 2 desc)
						       ""))
					      (desc (replace-regexp-in-string "\\(!style .+\\)" "" desc)))
					 (format "<form><button %s
			   formaction=\"%s\">%s</button></form>" style
			   path desc)))))


Example:

[[button:http://www.sambanya.com/artgallery.html][Art Gallery Page Link !style class="mybutton"]]

== HTML ==>

<p>
<form><button  class="mybutton" formaction="http://www.sambanya.com/artgallery.html">Art Gallery Page Link </button></form>
</p>


^ permalink raw reply	[relevance 12%]

* Re: Question Regarding Creating HTML Style Buttons With Org Mode
  2022-02-19  9:51 12%             ` Juan Manuel Macías
@ 2022-02-21  0:38  6%               ` Samuel Banya
  2022-02-23  2:25  1%                 ` Samuel Banya
  0 siblings, 1 reply; 200+ results
From: Samuel Banya @ 2022-02-21  0:38 UTC (permalink / raw)
  To: Charles Berry

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

Thanks for this, will try this for my Emacs config.

On Sat, Feb 19, 2022, at 4:51 AM, Juan Manuel Macías wrote:
> Juan Manuel Macías writes:
> 
> > If you want to pass the class or id 'manually' to each link, and thus
> > have more control, you can evaluate this other version, where the class
> > or id would be added at the end of the link description, after (for
> > example) "!style":
> 
> PS: Sorry, this is the correct code:
> 
>   (org-link-set-parameters "button"
>    :face '(:foreground "green4" :underline t)
>    :follow (lambda (path) (browse-url path))
>    :export (lambda (path desc backend)
>      (when (eq backend 'html)
>        (let ((style (if (string-match "\\(!style\\)\\(.+\\)" desc)
> (match-string 2 desc)
>        ""))
>       (desc (replace-regexp-in-string "\\(!style .+\\)" "" desc)))
> (format "<form><button %s
>    formaction=\"%s\">%s</button></form>" style
>    path desc)))))
> 
> 
> Example:
> 
> [[button:http://www.sambanya.com/artgallery.html][Art Gallery Page Link !style class="mybutton"]]
> 
> == HTML ==>
> 
> <p>
> <form><button  class="mybutton" formaction="http://www.sambanya.com/artgallery.html">Art Gallery Page Link </button></form>
> </p>
> 
> 

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

^ permalink raw reply	[relevance 6%]

* Footnote tooltips (an attempt)
@ 2022-02-22  4:32  9% Juan Manuel Macías
  2022-02-22 22:15 11% ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-22  4:32 UTC (permalink / raw)
  To: orgmode

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

Hi all,

I think sometimes it would be nice to have tooltips in the footnote
references, so I can see the contents of each footnote definition,
especially when I'm in a narrowed subtree; so I've tried to write some
code. I have achieved a "semi-automatic" solution. It doesn't work bad
at all, but I'm not entirely convinced either. With a minor mode the
`org-activate-footnote-links' function is overridden, and tooltips content
for all footnotes in the document are added or updated after a couple of
actions when you finish writing or editing a footnote:
`org-edit-src-exit' and `org-mark-ring-goto'. And that's where the
automatic part ends. Beyond that, tooltips must be updated/added by
calling the `my-org-fn-make-tooltips' function.

Here is a short video demo: https://cloud.disroot.org/s/a4gejYc6PSwNWHY

I attach the code of my poor man's footnote tooltips. Of course, any
comment and/or feedback is appreciated.

Best regards,

Juan Manuel


[-- Attachment #2: fn-tooltips.org --]
[-- Type: application/vnd.lotus-organizer, Size: 3405 bytes --]

^ permalink raw reply	[relevance 9%]

* Open a footnote definition outside a narrowed subtree (workaround)
@ 2022-02-22 16:04  8% Juan Manuel Macías
  2022-02-22 16:45  6% ` Nicolas Goaziou
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-22 16:04 UTC (permalink / raw)
  To: orgmode

Hi all,

When I am working on a narrowed subtree and want to open a footnote for
editing (`C-c C-o': `org-open-at-point'), I get the message: "Definition
is outside narrowed part of buffer". I don't know if there is a
"standard" solution for that (aside from cloning the buffer and/or
removing the restrictions)... I’ve written this simple and quick
workaround, and then remapped `C-c C-o' so that:

`C-u C-c C-o'
      my function
`C-c C-o'
      `org-open-at-point'

┌────
│ (defun my-org-open-fn-indirect-buffer ()
│   (interactive)
│   (if (not (equal (org-element-type (org-element-context)) 'footnote-reference))
│       (error "Not in a footnote reference!")
│     (let* ((el (org-element-context))
│ 	     (label (org-element-property :label el))
│ 	     (buf (buffer-name))
│ 	     (format (format "%s | Note %s" buf label)))
│       (when (get-buffer format)
│ 	(kill-buffer format))
│       (clone-indirect-buffer format t)
│       (setq header-line-format (format "NOTE %s" label))
│       (widen)
│       (org-open-at-point)
│       (recenter 0))))
│ 
│ (defun my-org-open-at-point ()
│   (interactive)
│   (if (equal current-prefix-arg nil)
│       (org-open-at-point)
│     (my-org-open-fn-indirect-buffer)))
│ 
│ (with-eval-after-load 'org
│   (define-key org-mode-map (kbd "C-c C-o") nil)
│   (define-key org-mode-map (kbd "C-c C-o") 'my-org-open-at-point))
└────

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 8%]

* Re: Open a footnote definition outside a narrowed subtree (workaround)
  2022-02-22 16:04  8% Open a footnote definition outside a narrowed subtree (workaround) Juan Manuel Macías
@ 2022-02-22 16:45  6% ` Nicolas Goaziou
  2022-02-22 17:34 10%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2022-02-22 16:45 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Hello,

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

> When I am working on a narrowed subtree and want to open a footnote for
> editing (`C-c C-o': `org-open-at-point'), I get the message: "Definition
> is outside narrowed part of buffer". I don't know if there is a
> "standard" solution for that (aside from cloning the buffer and/or
> removing the restrictions)...

The "standard" solution is to use <C-c '>

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[relevance 6%]

* Re: Open a footnote definition outside a narrowed subtree (workaround)
  2022-02-22 16:45  6% ` Nicolas Goaziou
@ 2022-02-22 17:34 10%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-22 17:34 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: orgmode

Nicolas Goaziou writes:

> The "standard" solution is to use <C-c '>

Thanks fot the tip!

org-edit-special > org-edit-footnote-reference: it's clearly explained
in the docstring, and I've been cloning buffers manually all my life
(facepalm).

Sorry for the noise, naturally the "standard" solution is preferable to my
workaround.

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 10%]

* Re: [PATCH] ox-latex.el: Add a `t' value for `:float' in tables and figures
  2022-02-16 19:52  8%       ` [PATCH] ox-latex.el: Add a `t' value for `:float' in tables and figures (was: update and add info for arbitrary :float values) Juan Manuel Macías
@ 2022-02-22 19:14  6%         ` Nicolas Goaziou
  0 siblings, 0 replies; 200+ results
From: Nicolas Goaziou @ 2022-02-22 19:14 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Hello,

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

> I am attaching an updated version of the patch, which retrieves the
> `t' value for `:float' in tables and figures. The necessary information in
> the Manual is also updated.

Applied. Thank you.

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[relevance 6%]

* Re: Footnote tooltips (an attempt)
  2022-02-22  4:32  9% Footnote tooltips (an attempt) Juan Manuel Macías
@ 2022-02-22 22:15 11% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-22 22:15 UTC (permalink / raw)
  To: orgmode

I answer myself to comment a couple more things on this question of
footnotes and tooltips. I think my approach is quite poor, and also when
it comes to files with many notes, it takes a long time to create or
update the list of tooltips. So I think I'll give up on' footnote
tooltips. If what it is about is being able to see the content of a
footnote quickly, I have written this other simpler function, which
displays the content of a footnote at point, in the echo area. Since
`<C-h .>' (`display-local-help') is not very useful in a footnote
reference, I recycle the shortcut for my function, if the context is a
footnote reference. I share it here, in case it is useful to someone.

┌────
│ (defun my-org-footnote-show-content ()
│   "Displays the content of a footnote at point, in the echo area"
│   (interactive)
│   (if (not (equal (org-element-type (org-element-context)) 'footnote-reference))
│       (error "Not on a footnote reference!")
│     (let* ((elt (org-element-context))
│          (label (org-element-property :label elt))
│          (def (org-with-wide-buffer
│                (org-footnote-goto-definition label)
│                (let* ((e (org-element-context))
│                       (from (org-element-property :contents-begin e))
│                       (to (org-element-property :contents-end e)))
│                  (buffer-substring-no-properties from to)))))
│       (message def))))
│
│ (defun mi-display-local-help ()
│   (interactive)
│   (if (and (derived-mode-p 'org-mode)
│          (equal (org-element-type (org-element-context)) 'footnote-reference))
│       (my-org-footnote-show-content)
│     (call-interactively 'display-local-help)))
│
│ (global-set-key (kbd "C-h .") 'mi-display-local-help)
└────

Best regards,

Juan Manuel

Juan Manuel Macías writes:

 Hi all,
>
> I think sometimes it would be nice to have tooltips in the footnote
> references, so I can see the contents of each footnote definition,
> especially when I'm in a narrowed subtree; so I've tried to write some
> code. I have achieved a "semi-automatic" solution. It doesn't work bad
> at all, but I'm not entirely convinced either. With a minor mode the
> `org-activate-footnote-links' function is overridden, and tooltips content
> for all footnotes in the document are added or updated after a couple of
> actions when you finish writing or editing a footnote:
> `org-edit-src-exit' and `org-mark-ring-goto'. And that's where the
> automatic part ends. Beyond that, tooltips must be updated/added by
> calling the `my-org-fn-make-tooltips' function.
>
> Here is a short video demo: https://cloud.disroot.org/s/a4gejYc6PSwNWHY
>
> I attach the code of my poor man's footnote tooltips. Of course, any
> comment and/or feedback is appreciated.
>
> Best regards,
>
> Juan Manuel
>
>


^ permalink raw reply	[relevance 11%]

* Re: Question Regarding Creating HTML Style Buttons With Org Mode
  2022-02-21  0:38  6%               ` Samuel Banya
@ 2022-02-23  2:25  1%                 ` Samuel Banya
  2022-02-23  2:33 10%                   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Samuel Banya @ 2022-02-23  2:25 UTC (permalink / raw)
  To: Charles Berry

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

Hey Juan,

Just wanted to let you know that this works beautifully!

I wish I was as good at Elisp to make this in the first place, but this really helps since I wanted to have some minimum overhead for 2 separate websites to be able to just write in Org Mode but include ideas for buttons, with classes and ID values.

This helps a ton, thanks so much as it totally worked! :)

Sincerely,

Sam

On Sun, Feb 20, 2022, at 7:38 PM, Samuel Banya wrote:
> Thanks for this, will try this for my Emacs config.
> 
> On Sat, Feb 19, 2022, at 4:51 AM, Juan Manuel Macías wrote:
>> Juan Manuel Macías writes:
>> 
>> > If you want to pass the class or id 'manually' to each link, and thus
>> > have more control, you can evaluate this other version, where the class
>> > or id would be added at the end of the link description, after (for
>> > example) "!style":
>> 
>> PS: Sorry, this is the correct code:
>> 
>>   (org-link-set-parameters "button"
>>    :face '(:foreground "green4" :underline t)
>>    :follow (lambda (path) (browse-url path))
>>    :export (lambda (path desc backend)
>>      (when (eq backend 'html)
>>        (let ((style (if (string-match "\\(!style\\)\\(.+\\)" desc)
>> (match-string 2 desc)
>>        ""))
>>       (desc (replace-regexp-in-string "\\(!style .+\\)" "" desc)))
>> (format "<form><button %s
>>    formaction=\"%s\">%s</button></form>" style
>>    path desc)))))
>> 
>> 
>> Example:
>> 
>> [[button:http://www.sambanya.com/artgallery.html][Art Gallery Page Link !style class="mybutton"]]
>> 
>> == HTML ==>
>> 
>> <p>
>> <form><button  class="mybutton" formaction="http://www.sambanya.com/artgallery.html">Art Gallery Page Link </button></form>
>> </p>
>> 
>> 
> 

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

^ permalink raw reply	[relevance 1%]

* Re: Footnote tooltips (an attempt)
  @ 2022-02-23  2:26  9%   ` Juan Manuel Macías
       [not found]         ` <CAJcAo8tsK5o+789Wv=i6ddiSrM4fDyX8HCvjAgDLXGyLXWRWmQ@mail.gmail.com>
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-23  2:26 UTC (permalink / raw)
  To: Ypo; +Cc: orgmode

Ypo writes:

> I love it!
> I am going to read your code, Juan Manuel, I won't understand anything
> but that function is very interesting for me, since it could be used
> too with internal links, I suppose.

Org links already have tooltips out of the box. You can also display the
tooltip in the echo area by pressing <C-h .> (`display-local-help').

If you want to try the code from my first post, please replace the
`my-org-fn-make-tooltips' function with this new version, which is much
simpler and doesn't have time-consuming issues to create or update
tooltips.

(However, I find the function I put in my second post more useful (for
my use case: I don't use the mouse very much).

#+begin_src emacs-lisp
  (defun my-org-fn-make-tooltips ()
    (interactive)
    (org-element-map (org-element-parse-buffer) 'footnote-reference
      (lambda (ref)
	(let* ((label (org-element-property :label ref))
	       (label-from (org-element-property :begin ref))
	       (label-to (org-element-property :end ref))
	       (def (org-with-wide-buffer
		     (org-footnote-goto-definition label)
		     (let* ((e (org-element-context))
			    (from (org-element-property :contents-begin e))
			    (to (org-element-property :contents-end e)))
		       (buffer-substring-no-properties from to))))
	       (tooltip def))
	  (add-text-properties label-from label-to
			       `(help-echo
				 ,tooltip))))
      nil nil))
#+end_src

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: Question Regarding Creating HTML Style Buttons With Org Mode
  2022-02-23  2:25  1%                 ` Samuel Banya
@ 2022-02-23  2:33 10%                   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-23  2:33 UTC (permalink / raw)
  To: Samuel Banya; +Cc: orgmode

Hi Samuel,

Samuel Banya writes:

> Hey Juan,
>
> Just wanted to let you know that this works beautifully!
>
> I wish I was as good at Elisp to make this in the first place, but
> this really helps since I wanted to have some minimum overhead for 2
> separate websites to be able to just write in Org Mode but include
> ideas for buttons, with classes and ID values.
>
> This helps a ton, thanks so much as it totally worked! :)

You're welcome! I'm glad it works and is useful to you. Org links
have great potential :-)

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: Bug with exporting list with link item containing "::" to markdown
  @ 2022-02-23 16:59  5% ` Max Nikulin
  0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-02-23 16:59 UTC (permalink / raw)
  To: Cash Weaver, emacs-orgmode

On 13/02/2022 03:12, Cash Weaver wrote:
> 
> As a quick summary: The following list item is improperly exported to 
> org mode (org-md-export-as-markdown). The first snippet is in org-mode 
> and the second is the exported markdown:
> 
> - [[id:c89158fd-05ac-4c66-8986-05753e15096c][ryans01 :: No Zero Days]]
> - [[id:92cf48f0-63a6-4d1d-9275-c80f6743ccb9][Do Things that Compound]]
> 
> -   **[[<ryans01NoZeroDays2013.md>][ryans01:** No Zero Days]]
> -   [Do Things that Compound](do_things_that_compound.md)

I am marking this issue as a bug for https://updates.orgmode.org/ but it 
may be just non-intuitive behavior of org-element parser. "::" inside an 
item forces the list to be considered as descriptive one. Element which 
parsing started earlier has higher priority. See the following recent 
thread for similar issues:

Juan Manuel Macías. Pandoc and nested emhases.
Fri, 18 Feb 2022 00:47:18 +0000.
https://list.orgmode.org/orgmode/87sfshgfvt.fsf@posteo.net/T/#u

You may add zero-width space between colons, see
info "(org) Escape Character" 
https://orgmode.org/manual/Escape-Character.html but it may require 
post-processing filter to remove zero-width spaces.

Another approach is to insert an export snippet:

- [[id:cbce567a-861c-4d9b-8b2f-5933afadb864][ryans01 :@@org:@@: No Zero 
Days]]



^ permalink raw reply	[relevance 5%]

* Re: Footnote tooltips (an attempt)
       [not found]         ` <CAJcAo8tsK5o+789Wv=i6ddiSrM4fDyX8HCvjAgDLXGyLXWRWmQ@mail.gmail.com>
@ 2022-02-23 19:52  9%       ` Juan Manuel Macías
  2022-02-23 22:05  4%         ` John Kitchin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-23 19:52 UTC (permalink / raw)
  To: Samuel Wales, Ypo; +Cc: orgmode

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

Hi Samuel,

Samuel Wales writes:

> what a great idea.  i am interested in your comments.  emacs has lots
> of tooltip-related features.  eldoc, help-at-pt, mouse-avoidance, etc.
> you don't want tooltips when your mouse happens to end up over.  or
> for your mouse to go haywire just because you ended up over.  i ran
> into a lot of confusion with various mechanisms.
>
> [e.g. i like having tooltips in echo area, and don't like eldoc for
> function sigs, and do want cursor/mouse consistency.]
>
> i found that some tooltip features actually break others.  just
> wondering if you noticed this and what you think of it.

I don't have much experience with Emacs tooltips and I haven't studied
them much, because I hardly use the mouse in Emacs :-) But I noticed
that you can also display the content of a tooltip in the echo area,
with `<C-h .>' (`display-local-help'), or even set to non-nil
`help-at-pt-display-when-idle' and evaluate `help-at-pt-set-timer', so
that a tootltip is displayed at point; and in this scenario, they can be
useful to me to quickly have some type of information.

You can also set this variable to force tooltips always in the echo
area:

(setq tooltip-use-echo-area t)

Anyway, I haven't given up on the idea of footnote tooltips yet. Here's
a new version of the code I attached in my first post in this thread,
and I think it's simpler now and works better, though I don't know if it
might have any side effects... Footnote tooltips are activated with the
minor mode `my-org-fn-tooltip-mode'.

A new demo video:

https://cloud.disroot.org/s/sBGJjCzbYgYbn5k

Best regards,

Juan Manuel


[-- Attachment #2: fn-tooltips.org --]
[-- Type: application/vnd.lotus-organizer, Size: 3004 bytes --]

^ permalink raw reply	[relevance 9%]

* Re: Footnote tooltips (an attempt)
  2022-02-23 19:52  9%       ` Juan Manuel Macías
@ 2022-02-23 22:05  4%         ` John Kitchin
  2022-02-24  2:04  8%           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: John Kitchin @ 2022-02-23 22:05 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Ypo, orgmode

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

I think this might be a simpler approach. what you want (I think) is to
leverage font-lock on tooltips to set a help-echo function instead of a
string. You can override org-activate-footnote-links with an advice (which
makes it easy to undo of you need). The tooltip function then looks up the
tooltip when you ask for it. The 3 pieces are below. the first function
looks up and returns a tooltip. the second is a lightly modified version of
org-activate-footnote-links which just replaces the footnote reference
string with the first function. the last piece is the override advice. you
could use a minor mode to toggle the advice on and off.




#+BEGIN_SRC emacs-lisp
(defun footnote-reference-tooltip (_win _obj position)
  "Get footnote contents"
  (save-excursion
    (goto-char position)
    (let* ((fnf (org-element-context))
  (label (org-element-property :label fnf))
  (p (nth 1 (org-footnote-get-definition label))))
      (when p
(goto-char p)))
    (let ((fnd (org-element-context)))
      (string-trim
       (buffer-substring (org-element-property :contents-begin fnd)
(org-element-property :contents-end fnd))))))


(defun footnote-tooltip (limit)
  "Add text properties for footnotes."
  (let ((fn (org-footnote-next-reference-or-definition limit)))
    (when fn
      (let* ((beg (nth 1 fn))
    (end (nth 2 fn))
    (label (car fn))
    (referencep (/= (line-beginning-position) beg)))
(when (and referencep (nth 3 fn))
 (save-excursion
   (goto-char beg)
   (search-forward (or label "fn:"))
   (org-remove-flyspell-overlays-in beg (match-end 0))))
(add-text-properties beg end
    (list 'mouse-face 'highlight
  'keymap org-mouse-map
  'help-echo
  (if referencep #'footnote-reference-tooltip
    "Footnote definition")
  'font-lock-fontified t
  'font-lock-multiline t
  'face 'org-footnote))))))

(advice-add 'org-activate-footnote-links :override 'footnote-tooltip)
#+END_SRC


John

-----------------------------------
John Kitchin (he/his)
Professor
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
http://kitchingroup.cheme.cmu.edu
https://pointbreezepubs.gumroad.com/ pycse bookstore


On Wed, Feb 23, 2022 at 2:52 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:

> Hi Samuel,
>
> Samuel Wales writes:
>
> > what a great idea.  i am interested in your comments.  emacs has lots
> > of tooltip-related features.  eldoc, help-at-pt, mouse-avoidance, etc.
> > you don't want tooltips when your mouse happens to end up over.  or
> > for your mouse to go haywire just because you ended up over.  i ran
> > into a lot of confusion with various mechanisms.
> >
> > [e.g. i like having tooltips in echo area, and don't like eldoc for
> > function sigs, and do want cursor/mouse consistency.]
> >
> > i found that some tooltip features actually break others.  just
> > wondering if you noticed this and what you think of it.
>
> I don't have much experience with Emacs tooltips and I haven't studied
> them much, because I hardly use the mouse in Emacs :-) But I noticed
> that you can also display the content of a tooltip in the echo area,
> with `<C-h .>' (`display-local-help'), or even set to non-nil
> `help-at-pt-display-when-idle' and evaluate `help-at-pt-set-timer', so
> that a tootltip is displayed at point; and in this scenario, they can be
> useful to me to quickly have some type of information.
>
> You can also set this variable to force tooltips always in the echo
> area:
>
> (setq tooltip-use-echo-area t)
>
> Anyway, I haven't given up on the idea of footnote tooltips yet. Here's
> a new version of the code I attached in my first post in this thread,
> and I think it's simpler now and works better, though I don't know if it
> might have any side effects... Footnote tooltips are activated with the
> minor mode `my-org-fn-tooltip-mode'.
>
> A new demo video:
>
> https://cloud.disroot.org/s/sBGJjCzbYgYbn5k
>
> Best regards,
>
> Juan Manuel
>
>

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

^ permalink raw reply	[relevance 4%]

* Re: Footnote tooltips (an attempt)
  2022-02-23 22:05  4%         ` John Kitchin
@ 2022-02-24  2:04  8%           ` Juan Manuel Macías
  2022-02-24 13:01  6%             ` John Kitchin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-24  2:04 UTC (permalink / raw)
  To: John Kitchin; +Cc: orgmode

Hi John,

John Kitchin writes:

> I think this might be a simpler approach. what you want (I think) is
> to leverage font-lock on tooltips to set a help-echo function instead
> of a string. You can override org-activate-footnote-links with an
> advice (which makes it easy to undo of you need). The tooltip function
> then looks up the tooltip when you ask for it. The 3 pieces are below.
> the first function looks up and returns a tooltip. the second is a
> lightly modified version of org-activate-footnote-links which just
> replaces the footnote reference string with the first function. the
> last piece is the override advice. you could use a minor mode to
> toggle the advice on and off.

Thank you very much for your comment and code, which has helped me to
clarify my ideas. Your approach is in a certain way similar to the last
version of my attempt, which I attached in the previous message: through
a first function I get the definition of each note, which is returned as
a text string. And I also override via `advice-add'
'org-activate-footnonte-links' with a new function, which is also
slightly modified, including a variable that gets the tooltip from the
first function. The problem is that with my approach the tooltip does
not appear on the fly, but when the next note is added. I think what my
first function (the one that gets the footnote definition) was missing
was the three arguments of your first function: `_win _obj position' and
the (goto-char position), and pass it as a symbol (not as a variable) to
the second function that overrides org-activate-footnote-links, as you
do in your code. Modifying my function from your code, it would look
something like this:

(defun my-org-fn-get-def (_win _obj position)
  (save-excursion
    (goto-char position)
    (let* ((el (org-element-context))
           (label (org-element-property :label el))
           (def (nth 3 (org-footnote-get-definition label))))
      (when def (concat "Footnonte: " def)))))

And it seems that now the tooltips appear instantly, and are updated in
real time.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: Pandoc and nested emhases
  2022-02-18 12:31 10%   ` Juan Manuel Macías
@ 2022-02-24 12:50  5%     ` Max Nikulin
  0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-02-24 12:50 UTC (permalink / raw)
  To: emacs-orgmode

On 18/02/2022 19:31, Juan Manuel Macías wrote:
> Max Nikulin writes:
> 
>> So formally this feature of pandoc is a bug (due to different kind of
>> parser). It is the reason why a corpus of tests should exist in a
>> format that can be easily imported from various programming languages.
> 
> Your conclusions seem logical to me. It may sound a bit surrealistic to
> think that Pandoc is doing it wrong precisely for doing it "right", but...

Even pandoc is not perfect (at least not really consistent):

printf '%s' '- [[https://orgmode.org/][Lorem :: Ipsum]]' \
   | pandoc -f org -t html
<dl>
<dt>[[<a href="https://orgmode.org/">https://orgmode.org/</a>][Lorem</dt>
<dd>Ipsum]]
</dd>
</dl>

Default zero-width workaround does not work for e.g. for code snippets 
since it would break syntax of target programming language:

printf '%s' '- src_haskell{monoidBSFold :: FilePath -> IO Counts}' \
   | pandoc -f org -t html

Examples are inspired by the following message:

Cash Weaver. Bug with exporting list with link item containing "::" to 
markdown. Sat, 12 Feb 2022 12:12:45 -0800.
https://list.orgmode.org/CABGRHLkLGXYgGNm4CXK_LjOTGTpsLO=5aWD=FyPd1aMy2QdBxw@mail.gmail.com



^ permalink raw reply	[relevance 5%]

* Re: Footnote tooltips (an attempt)
  2022-02-24  2:04  8%           ` Juan Manuel Macías
@ 2022-02-24 13:01  6%             ` John Kitchin
  2022-02-24 16:25 10%               ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: John Kitchin @ 2022-02-24 13:01 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

that is a nice solution. I probably should have read the docstring on
org-footnote-get-definition  a little more closely, it has the definition
you need in it!

John

-----------------------------------
John Kitchin (he/his)
Professor
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
http://kitchingroup.cheme.cmu.edu
https://pointbreezepubs.gumroad.com/ pycse bookstore


On Wed, Feb 23, 2022 at 9:04 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:

> Hi John,
>
> John Kitchin writes:
>
> > I think this might be a simpler approach. what you want (I think) is
> > to leverage font-lock on tooltips to set a help-echo function instead
> > of a string. You can override org-activate-footnote-links with an
> > advice (which makes it easy to undo of you need). The tooltip function
> > then looks up the tooltip when you ask for it. The 3 pieces are below.
> > the first function looks up and returns a tooltip. the second is a
> > lightly modified version of org-activate-footnote-links which just
> > replaces the footnote reference string with the first function. the
> > last piece is the override advice. you could use a minor mode to
> > toggle the advice on and off.
>
> Thank you very much for your comment and code, which has helped me to
> clarify my ideas. Your approach is in a certain way similar to the last
> version of my attempt, which I attached in the previous message: through
> a first function I get the definition of each note, which is returned as
> a text string. And I also override via `advice-add'
> 'org-activate-footnonte-links' with a new function, which is also
> slightly modified, including a variable that gets the tooltip from the
> first function. The problem is that with my approach the tooltip does
> not appear on the fly, but when the next note is added. I think what my
> first function (the one that gets the footnote definition) was missing
> was the three arguments of your first function: `_win _obj position' and
> the (goto-char position), and pass it as a symbol (not as a variable) to
> the second function that overrides org-activate-footnote-links, as you
> do in your code. Modifying my function from your code, it would look
> something like this:
>
> (defun my-org-fn-get-def (_win _obj position)
>   (save-excursion
>     (goto-char position)
>     (let* ((el (org-element-context))
>            (label (org-element-property :label el))
>            (def (nth 3 (org-footnote-get-definition label))))
>       (when def (concat "Footnonte: " def)))))
>
> And it seems that now the tooltips appear instantly, and are updated in
> real time.
>
> Best regards,
>
> Juan Manuel
>

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

^ permalink raw reply	[relevance 6%]

* Re: Footnote tooltips (an attempt)
  2022-02-24 13:01  6%             ` John Kitchin
@ 2022-02-24 16:25 10%               ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-24 16:25 UTC (permalink / raw)
  To: John Kitchin; +Cc: orgmode

John Kitchin writes:

> that is a nice solution. I probably should have read the docstring on
> org-footnote-get-definition  a little more closely, it has the
> definition you need in it!

Well, it's a minor detail. The really brilliant thing here is your idea
of passing the function as a help-echo value, instead of a text string.
It works like a charm! :-).

(I didn't know that the help-echo property could accept a function as a
value, and reading the documentation I realize that this has a lot of
potential...).

Best regards, And thanks again,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: ConTeXt exporter makes me happy
  @ 2022-02-24 19:58  9% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-24 19:58 UTC (permalink / raw)
  To: juh; +Cc: orgmode

juh writes:

> thanks a lot for org-mode and the ConTeXt exporter.
> https://github.com/Jason-S-Ross/ox-context
>
> With your help, in the last few months I setup a complete authoring and
> publishing environment for my needs with org-mode and ox-context. I
> collect my thoughts with org-roam, outline and write my texts with Emacs
> and org-mode and typeset my books with ConTeXt. Perfect match!
>
> ConTeXt is a wonderful tool to typeset books. It is much more flexible
> than LaTeX and very powerful.
>
> Before ox-context my authoring and publishing setup was a combination of
> Markdown, Pandoc and ConTeXt. It was quite perfect and handsome. The
> only drawback of this setup is the break between my Zettelkasten
> (org-roam) and my publishing tools.
>
> So, I am very happy that ox-context is there and is continually
> improved.  The possibility to export to ConTeXt is a good reason to
> learn more facets of org-mode which is quite a big beast.

Although I prefer LaTeX to ConTeXt for my typesetting and publishing
work, I agree that ConTeXt is an excellent tool, and for many users it
can provide a number of advantages over LaTeX. I agree also that Jason
has done a great job with ox-context, and I join in the congratulations.

I recommend LaTeX users, and even users of LaTeX via Org-Mode, to give
ConTeXt a try, if you haven't tried it yet. And of course try
ox-context. One of the historical drawbacks of ConTeXt has always been
its poor documentation, compared to LaTeX's documentation (it's not
really deficient, but what abounds is the documentation at a more
technical level). But luckily there is now an excellent ConTeXt
introductory manual, written by Joaquín Ataz López and with translations
(so far) into English, French, Russian and Serbian:

https://github.com/contextgarden/not-so-short-introduction-to-context

Best regards,

Juan Manuel



^ permalink raw reply	[relevance 9%]

* Re: including one double quote in an anonymous footnote?
  @ 2022-02-26 14:47 10% ` Juan Manuel Macías
    0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-26 14:47 UTC (permalink / raw)
  To: Greg Minshall; +Cc: orgmode

Hi Greg,

Greg Minshall writes:

> hi.  experimenting [after significant confusion!], it appears that
> including a single (unpaired) double quote inside an anonymous footnote
> eliminates the recognition of the footnote.  is this intentional?
>
> this works:
> ----
> this is a test.[fn:: a very long footnote]
> ----
>
> whereas this doesn't:
> ----
> this is a test.[fn:: "a very long footnote]
> ----
>
> i notice that for purposes of exporting, i can have the single double
> quote accepted by escaping it with a backslash:
> ----
> this is a test.[fn:: \"a very long footnote]
> ----
> but,
> - the backslash itself shows up in both latex and html exporting
> - the footnote doesn't get displayed in the org buffer as a footnote
>   (the separate colors; this is "font locking"?)
>
> Org mode version 9.5.2 (9.5.2-gbb6830 @ /home/minshall/.emacs.d/straight/build/org/)

I can confirm that behavior. One possible solution is to use an entity
(M-x org-entities-help):

this is a test.[fn:: \quot{}a very long footnote]

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: including one double quote in an anonymous footnote?
  @ 2022-02-26 19:20  9%     ` Juan Manuel Macías
  2022-02-28 14:47  6%       ` Nicolas Goaziou
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-26 19:20 UTC (permalink / raw)
  To: Greg Minshall; +Cc: orgmode

Greg Minshall writes:

> Juan Manuel,
>
>> I can confirm that behavior. One possible solution is to use an entity
>> (M-x org-entities-help):
>
> thanks very much -- that does the trick for my case.

In any case, I don't know if that behavior should be considered a bug. I
say this because other constructions with an unbalanced element,
although org does not fontify them well, they are exported correctly:

this is a test[fn::(this is an inline footnote]

this is a test[fn::{this is an inline footnote]

== LaTeX ==>

this is a test\footnote{(this is an inline footnote}

this is a test\footnote{\{this is an inline footnote}

Instead, if you do <M-: (org-element-context)> on your example,
org-element-context doesn't recognize this as a footnote reference:

this is a test[fn::"this is an inline footnote]

Looking at `org-element-footnote-reference-parser', I'd say the problem
is with:

...
(with-syntax-table org-element--pair-square-table
		       (ignore-errors (scan-lists (point) 1 0)))
...

If there is an unbalanced double quote inside a bracket construction,
that expression returns nil and not the position after the final
bracket. But I don't know how to go on :-(.

Best regards,

Juan Manuel 






^ permalink raw reply	[relevance 9%]

* Re: including one double quote in an anonymous footnote?
  2022-02-26 19:20  9%     ` Juan Manuel Macías
@ 2022-02-28 14:47  6%       ` Nicolas Goaziou
    0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2022-02-28 14:47 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Greg Minshall, orgmode

Hello,

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

> Greg Minshall writes:

> In any case, I don't know if that behavior should be considered a bug. I
> say this because other constructions with an unbalanced element,
> although org does not fontify them well, they are exported correctly:
>
> this is a test[fn::(this is an inline footnote]
>
> this is a test[fn::{this is an inline footnote]
>
> == LaTeX ==>
>
> this is a test\footnote{(this is an inline footnote}
>
> this is a test\footnote{\{this is an inline footnote}
>
> Instead, if you do <M-: (org-element-context)> on your example,
> org-element-context doesn't recognize this as a footnote reference:
>
> this is a test[fn::"this is an inline footnote]
>
> Looking at `org-element-footnote-reference-parser', I'd say the problem
> is with:
>
> ...
> (with-syntax-table org-element--pair-square-table
> 		       (ignore-errors (scan-lists (point) 1 0)))
> ...
>
> If there is an unbalanced double quote inside a bracket construction,
> that expression returns nil and not the position after the final
> bracket. But I don't know how to go on :-(.

I think I fixed it in bugfix branch. Thanks.

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[relevance 6%]

* Re: including one double quote in an anonymous footnote?
  @ 2022-02-28 20:57 10%           ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-28 20:57 UTC (permalink / raw)
  To: Greg Minshall; +Cc: orgmode, Nicolas Goaziou

Hi Greg and Nicolas,

Greg Minshall writes:

> Nicolas and Juan Manuel,
>
> thanks very much.  the bugfix branch seems to work for my case.

Thank you very much Nicolas. In my case it also works fine.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Move or rename a file in a link
@ 2022-03-05 19:58  9% Juan Manuel Macías
  2022-03-06  8:09  3% ` Uwe Brauer
  2022-03-09 20:30  6% ` João Pedro de Amorim Paula
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-05 19:58 UTC (permalink / raw)
  To: orgmode

Hi all,

I have written this simple function to move or rename a destination file
in an external link at point. I share it here in case it is useful to
someone.

Best regards,

Juan Manuel 

#+begin_src emacs-lisp
(defun my-org-replace-link-file (from to)
  (save-excursion
    (goto-char (point-min))
    (while (re-search-forward org-bracket-link-regexp nil t)
      (when (string-match-p from (match-string 1))
	(replace-match (concat "[[file:" to "]]"))))))

(defun my-org-rename-link-file-at-point ()
  "Rename or move a file in an external link at point and
  update the link path"
  (interactive)
  (let* ((curr-dir (abbreviate-file-name default-directory))
	 (current-path (org-element-property :path (org-element-context)))
	 (new-path (read-file-name "Rename file at point to: " current-path)))
    (rename-file current-path new-path)
    (message (concat "moved to: " new-path))
    (if (directory-name-p new-path)
	(setq new-path (concat new-path (file-name-nondirectory current-path)))
      (setq new-path new-path))
    (my-org-replace-link-file current-path
			      (replace-regexp-in-string curr-dir "" new-path))))

#+end_src


^ permalink raw reply	[relevance 9%]

* Re: Filter for HTML footnotes?
  @ 2022-03-06  4:03  9% ` Juan Manuel Macías
  2022-03-08  7:40  5%   ` Filter for HTML (cite) footnotes? M. ‘quintus’ Gülker
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-03-06  4:03 UTC (permalink / raw)
  To: M. ‘quintus’ Gülker; +Cc: orgmode

M. ‘quintus’ Gülker writes:

> I recently discovered export filters and found some useful applications
> for them. For instance, the scientific domain I work in (law) uses
> footnote citations, and in these footnotes we abbreviate some words
> which would otherwise be written out in ordinary text, like name
> particles. Since I use org-cite these footnotes are automatically
> generated. So what I did was to write a filter which abbreviates these
> words on export in footnotes. I added the filter function to both
> org-export-filter-footnote-definition-functions and
> org-export-filter-footnote-reference-functions and indeed, when I export
> to LaTeX or ODT it does its job just fine. However, when I export to
> HTML instead, it does not. When I looked at the text passed to the
> filter when exporting as HTML, it turned out what the function receives
> is not the content of the footnote, but only the markup for the footnote
> number. That came a bit by surprise.

> So, what is the correct way to target the content of a footnote in a
> filter across backends?

Hi,

I think a function for `org-export-filter-parse-tree-functions' would
work better here. For example, this function replaces "lorem ipsum" with
"foo" in all footnote definitions:

#+BIND: org-export-filter-parse-tree-functions (fnt-filter-replace)

#+begin_src emacs-lisp :exports results :results none
  (defun fnt-filter-replace (tree backend info)
    (org-element-map tree 'footnote-definition
      (lambda (fnt)
	(let* ((contents (org-element-interpret-data
			  (org-element-contents fnt)))
	       (contents-new (with-temp-buffer
			       (insert contents)
			       (save-excursion
				 (goto-char (point-min))
				 (while (re-search-forward "lorem ipsum" nil t)
				   (replace-match "foo" t nil)))
			       (org-element-parse-buffer))))
	  (apply #'org-element-set-contents
		 fnt
		 (list contents-new))))
      info)
    tree)
#+end_src

Best regards,

Juan Manuel 



^ permalink raw reply	[relevance 9%]

* Re: Move or rename a file in a link
  2022-03-05 19:58  9% Move or rename a file in a link Juan Manuel Macías
@ 2022-03-06  8:09  3% ` Uwe Brauer
  2022-03-09 20:30  6% ` João Pedro de Amorim Paula
  1 sibling, 0 replies; 200+ results
From: Uwe Brauer @ 2022-03-06  8:09 UTC (permalink / raw)
  To: emacs-orgmode

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

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

Hi Juan Manuel 


> Hi all,
> I have written this simple function to move or rename a destination file
> in an external link at point. I share it here in case it is useful to
> someone.

Thanks, that looks very useful, I tend to reorder files in
subdirectories and therefore «destroying links»

Uwe Brauer 

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

^ permalink raw reply	[relevance 3%]

* Re: interleaving comment between rows of a table?
  @ 2022-03-07 15:54 10% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-07 15:54 UTC (permalink / raw)
  To: Greg Minshall; +Cc: orgmode

Hi Greg,

Greg Minshall writes:

> i don't remember anybody asking about this.
>
> i'd sometimes find it useful to be able to interleave comments -- using
> (almost) whatever syntax -- between rows in an org-mode table.
> (normally, this would be to provide context/rationale for the subsequent
> row(s).)

I find the annotate package useful for inserting comments and
annotations in "difficult" places. I find annotations in the margin (as
overlays) intrusive, so I have set this variable, so that the
annotations appear only in the echo area and as a tooltip:

(setq annotate-use-echo-area t)

See this screenshot: https://i.imgur.com/koKYL0K.png

Other possible settings for annotate:

(set-face-attribute 'annotate-highlight nil :foreground "chocolate" :background nil :underline nil)

(set-face-attribute 'annotate-highlight-secondary nil :foreground "chocolate" :background nil :underline nil)

(setq annotate-file "path/to/my/annotate/file")

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: Filter for HTML (cite) footnotes?
  2022-03-06  4:03  9% ` Juan Manuel Macías
@ 2022-03-08  7:40  5%   ` M. ‘quintus’ Gülker
  2022-03-08 10:14 10%     ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: M. ‘quintus’ Gülker @ 2022-03-08  7:40 UTC (permalink / raw)
  To: emacs-orgmode

Hi,

Am Sonntag, dem 06. März 2022 schrieb Juan Manuel Macías:
> I think a function for `org-export-filter-parse-tree-functions' would
> work better here. For example, this function replaces "lorem ipsum" with
> "foo" in all footnote definitions:

I have tried this suggestion, but it does not appear to work with
org-cite’s automatically generated footnotes. Text is only changed in
ordinary footnotes already present in the org file. When I use org-cite
with citeproc.el with a CSL style demanding footnotes, these citational
footnotes are generated from the [cite:] constructs somewhere inside
org-cite and/or citeproc.el during the export process. These footnotes
are apparantly not subject to “org-export-filter-parse-tree-functions”,
probably because they are inserted after parsing has completed.

That is, what I am after effectively, is post-processing the results
generated by org-cite resp. citeproc.el. I have names in my
bibliographic database like “Axel von Hellfeld”, which contain the
German name particle “von”. Some (not all) citation customs require
“von” to be abbreviated to “v.” so that the cited name becomes
“v. Hellfeld”. This is not possible with CSL, so I look for another
way to automate this during the export process.

  -quintus

--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kontakt@guelker.eu    | O<


^ permalink raw reply	[relevance 5%]

* Re: Filter for HTML (cite) footnotes?
  2022-03-08  7:40  5%   ` Filter for HTML (cite) footnotes? M. ‘quintus’ Gülker
@ 2022-03-08 10:14 10%     ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-08 10:14 UTC (permalink / raw)
  To: M. ‘quintus’ Gülker; +Cc: orgmode

M. ‘quintus’ Gülker writes:

> That is, what I am after effectively, is post-processing the results
> generated by org-cite resp. citeproc.el. I have names in my
> bibliographic database like “Axel von Hellfeld”, which contain the
> German name particle “von”. Some (not all) citation customs require
> “von” to be abbreviated to “v.” so that the cited name becomes
> “v. Hellfeld”. This is not possible with CSL, so I look for another
> way to automate this during the export process.

I see. Have you tried using `org-export-filter-final-output-functions'?
You can try a find/replace function for the footnotes of final
output. The drawback is that the scope here is broader and
care should be taken with false positives...

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: Move or rename a file in a link
  2022-03-05 19:58  9% Move or rename a file in a link Juan Manuel Macías
  2022-03-06  8:09  3% ` Uwe Brauer
@ 2022-03-09 20:30  6% ` João Pedro de Amorim Paula
  2022-03-10 14:58 10%   ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: João Pedro de Amorim Paula @ 2022-03-09 20:30 UTC (permalink / raw)
  To: Juan Manuel Macías, orgmode

On 05 March 2022 19:58, Juan Manuel Macías <maciaschain@posteo.net> wrote:

Hello Juan!

> Hi all,
>
> I have written this simple function to move or rename a destination file
> in an external link at point. I share it here in case it is useful to
> someone.
>
> Best regards,
>
> Juan Manuel 
>
> #+begin_src emacs-lisp
> (defun my-org-replace-link-file (from to)
>   (save-excursion
>     (goto-char (point-min))
>     (while (re-search-forward org-bracket-link-regexp nil t)
>       (when (string-match-p from (match-string 1))
> 	(replace-match (concat "[[file:" to "]]"))))))
>
> (defun my-org-rename-link-file-at-point ()
>   "Rename or move a file in an external link at point and
>   update the link path"
>   (interactive)
>   (let* ((curr-dir (abbreviate-file-name default-directory))
> 	 (current-path (org-element-property :path (org-element-context)))
> 	 (new-path (read-file-name "Rename file at point to: " current-path)))
>     (rename-file current-path new-path)
>     (message (concat "moved to: " new-path))
>     (if (directory-name-p new-path)
> 	(setq new-path (concat new-path (file-name-nondirectory current-path)))
>       (setq new-path new-path))
>     (my-org-replace-link-file current-path
> 			      (replace-regexp-in-string curr-dir "" new-path))))
>
> #+end_src
>

Thanks for sharing! It'd be great if it worked for attachments as well,
but that is a whole can of worms.

Cheers,

-- 
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

^ permalink raw reply	[relevance 6%]

* Re: Move or rename a file in a link
  2022-03-09 20:30  6% ` João Pedro de Amorim Paula
@ 2022-03-10 14:58 10%   ` Juan Manuel Macías
  2022-03-18 18:52  6%     ` João Pedro de Amorim Paula
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-03-10 14:58 UTC (permalink / raw)
  To: João Pedro de Amorim Paula; +Cc: orgmode

Hi João, Thanks for your comment.

João Pedro de Amorim Paula writes:

> Thanks for sharing! It'd be great if it worked for attachments as well,
> but that is a whole can of worms.

Regarding attachments, do you mean org attachments or email attachments?
Could you give an example of a use case?

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* helm-org-names: browse the names of code blocks, tables and figures
@ 2022-03-11 22:24 10% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-11 22:24 UTC (permalink / raw)
  To: orgmode

Hi all,

I've written this little package to browse with helm through the names
of code blocks, tables and figures in a document. A series of actions
can be executed on the candidate (go to object, edit a code block,
insert a link, etc.). In the list of figures that is displayed in Helm,
each figure name is accompanied by a thumbnail of the image.

A screenshot: https://i.imgur.com/DVIQv8x.png

The GitLab repo:

https://gitlab.com/maciaschain/helm-org-names

I'm afraid the package is still a bit raw, but I think it's usable :-).

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 10%]

* Re: Code blocks and quotes export style
  @ 2022-03-13 18:39  7%   ` Juan Manuel Macías
  2022-03-14 12:50  6%     ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-03-13 18:39 UTC (permalink / raw)
  To: Kaushal Modi; +Cc: orgmode, Sébastien Gendre

Kaushal Modi writes:

> Well, that will at least help the code blocks going out of bounds. It
> won't help the quotes. 

With the quotes going out of bounds issue it would be nice to see a
screenshot. But if a line of normal text goes outside the margin, it is
usually due to a TeX overfull hbox, perhaps because TeX hasn't been able
to hyphenate a long word correctly (also perhaps because the text is in
a language other than the main language, and that text should be encased
in the secondary language specifications).

For this type of lines outside the margin there are several LaTeX
solutions:

The quick fix is to add a discretionary hyphen (\-). For example, if the
word that goes outside the margin is "supercalifragilistic", the
discretionary can be added with an export snipett:

Supercali@@latex:\-@@fragilistic

Or even breakpoints can be indicated with the '\hyphenation' macro in the
preamble (we can add a list of words separated by commas):

#+LaTeX_Header: \hyphenation{Supercali-fragilistic}

Another solution is to disable TeX's line break algorithm at the
paragraph where the line overflows, using the slopypar environment. The
result can be ugly, with too wide separations between words.

On the other hand, loading the microtype package (in pdfTeX or LuaTeX)
usually helps a lot in the construction of the paragraphs.

And finally, if LuaTeX is used to compile, the linebreaker
(https://www.ctan.org/pkg/linebreaker) package automatically prevents
all overfull hboxes in the document.

Also note that the Org quote block supports the :environments attribute,
where we can apply environments other than 'quote', such as quotation or
those provided by the csquotes package. For example, for quotes in
another language:

#+LaTeX_Header:\usepackage[german,english]{babel}
#+LaTeX_Header:\usepackage{quoting}
#+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
#+LaTeX_Header:\SetBlockEnvironment{quoting}
#+ATTR_LaTeX: :environment foreigndisplayquote :options {german}
#+begin_quote
Eine Erklärung, wie sie einer Schrift in einer Vorrede nach der
Gewohnheit vorausgeschickt wird (Hegel).
#+end_quote

Best regards,

Juan Manuel 




^ permalink raw reply	[relevance 7%]

* Re: Code blocks and quotes export style
  2022-03-13 18:39  7%   ` Juan Manuel Macías
@ 2022-03-14 12:50  6%     ` Max Nikulin
  2022-03-14 18:09 10%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-03-14 12:50 UTC (permalink / raw)
  To: emacs-orgmode

On 14/03/2022 01:39, Juan Manuel Macías wrote:
> 
> Supercali@@latex:\-@@fragilistic

     Supercali\shy{}fragilistic
     Supercali\-fragilistic


should be even better since, besides LaTeX "\-", HTML exporter uses 
"&shy;" or "&#x00ad;" (I would expect more consistent behavior though.)

info "(org) Special Symbols" 
https://orgmode.org/manual/Special-Symbols.html [[info:org#Special Symbols]]



^ permalink raw reply	[relevance 6%]

* Re: Code blocks and quotes export style
  2022-03-14 12:50  6%     ` Max Nikulin
@ 2022-03-14 18:09 10%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-14 18:09 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

Max Nikulin writes:

> should be even better since, besides LaTeX "\-", HTML exporter uses
> "&shy;" or "&#x00ad;" (I would expect more consistent behavior
> though.)

Hi, Maxim. You're right, I didn't remember that there is a specific
entity in Org for the discretionary hyphen. Sometimes I think too much
from the LaTeX side... :-)

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: LaTeX export of a file with some accented characters
  @ 2022-03-15 20:23 10% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-15 20:23 UTC (permalink / raw)
  To: Vikas Rawal; +Cc: orgmode

Hi Vikas,

Vikas Rawal writes:

> I have an org file with some names (not all) that have accented
> characters. But when I try to export, I get errors such as this:
>
> Sāṅkr - 65190: word not found
>
> What do I do to make Org export these correctly? Is there a way to
> make Org export even if it does not recognise the characters?

Do you have flyspell-mode active? Sounds to me like that's a flyspell
error message, but it's weird anyway and I don't know how to fit it into
your export issue...

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: leading superscript on a line for ODT export
  @ 2022-03-16 12:03 10% ` Juan Manuel Macías
  2022-03-16 12:46  6%   ` Eric S Fraga
    1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-03-16 12:03 UTC (permalink / raw)
  To: Eric S Fraga; +Cc: orgmode

Hi Eric,

Eric S Fraga writes:

> I need to have a line starting with a superscript, e.g. 1, in an ODT
> exported file.  If I write "^1 blah", it doesn't work.  I need a
> character before the ^ to have it interpreted as a superscript.
>
> Is there an "empty" character I can use?  I tried a non-breaking space
> but that did not work.  The space is there but the ^1 gets exported
> literally.

I would use a macro. For example:

#+begin_src emacs-lisp 
  (defun my-macro-superscript (arg)
     (cond ((eq org-export-current-backend 'latex)
	   (format "@@latex:\\textsuperscript{%s}@@" arg))
	  ((eq org-export-current-backend 'odt)
	   (format "@@odt:<text:span text:style-name=\"OrgSuperscript\">%s</text:span>@@" arg))))

  (setq org-export-global-macros
	'(("sup" . "(eval (my-macro-superscript $1))")))
#+end_src

{{{sup(4)}}}

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: leading superscript on a line for ODT export
  2022-03-16 12:03 10% ` Juan Manuel Macías
@ 2022-03-16 12:46  6%   ` Eric S Fraga
  2022-03-16 13:12 10%     ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Eric S Fraga @ 2022-03-16 12:46 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On Wednesday, 16 Mar 2022 at 12:03, Juan Manuel Macías wrote:
> I would use a macro. For example:

Yes, I guess this is the best way to do this.  Thank you in particular
for the xml code for odt which would have taken me some time to figure
out!

-- 
: Eric S Fraga, with org release_9.5.2-401-g91681f in Emacs 29.0.50


^ permalink raw reply	[relevance 6%]

* Re: leading superscript on a line for ODT export
  2022-03-16 12:46  6%   ` Eric S Fraga
@ 2022-03-16 13:12 10%     ` Juan Manuel Macías
  2022-03-16 13:42  6%       ` Eric S Fraga
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-03-16 13:12 UTC (permalink / raw)
  To: Eric S Fraga; +Cc: orgmode

Eric S Fraga writes:

> Yes, I guess this is the best way to do this.  Thank you in particular
> for the xml code for odt which would have taken me some time to figure
> out!

When I need to find out some xml markup in odt or docx I open the
document from Dired with view-mode, and run C-c C-c
(doc-view-toggle-display) to access the .xml files (these documents are
nothing more than zipped folders with xml files inside). This is also
useful for making (small) modifications to an odt or docx document. So,
yeah, in Emacs we can edit a Word or Libreoffice document :-D.

A screenshot: https://i.imgur.com/XRcGwse.png

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: leading superscript on a line for ODT export
  2022-03-16 13:12 10%     ` Juan Manuel Macías
@ 2022-03-16 13:42  6%       ` Eric S Fraga
  0 siblings, 0 replies; 200+ results
From: Eric S Fraga @ 2022-03-16 13:42 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On Wednesday, 16 Mar 2022 at 13:12, Juan Manuel Macías wrote:
> When I need to find out some xml markup in odt or docx I open the
> document from Dired with view-mode, and run C-c C-c

Yeah, I've done this in the past as well.  Dired and automatic
un-zipping really helps!

Thanks again,
eric

-- 
: Eric S Fraga, with org release_9.5.2-401-g91681f in Emacs 29.0.50


^ permalink raw reply	[relevance 6%]

* Re: leading superscript on a line for ODT export
  @ 2022-03-16 14:07 10%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-16 14:07 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode, Eric S Fraga

Max Nikulin writes:

>     @@org:@@^1 blah

This is a nice solution. I think a snipet with a "non-existent" backend
would work here too:

@@null:@@^1

(I use a lot export snipets with 'non-existent' backends for inline
comments).

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Org and multimedia (tips?)
@ 2022-03-17 22:44  7% Juan Manuel Macías
  2022-03-18 14:40  6% ` Max Nikulin
  2022-05-05  1:14  5% ` TRS-80
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-17 22:44 UTC (permalink / raw)
  To: orgmode

Hi all,

I've been trying for a while to use Org also to store and org-anize the
data of my music and video files, so that I can conveniently access them
via helm-org-ql and play them using EMMS. I was wondering if anyone is
trying this too, and thought maybe it would be nice to share tips and
hacks.

What I do is quite simple and rudimentary. For example, I have all my
music files stored on a hard drive on my Raspberry. As a media server I
use GNUMP3d, which is pretty clunky and outdated, but it works fine and
is very easy for me to administer. GNUMP3d serves a local web page with
the list of titles and artists. I convert that web to an Org node using
org-web-tools (https://github.com/alphapapa/org-web-tools), and some
extra elisp to clean up inconsistencies and format everything so that
each artist/title is a sub-tree. The process is not quite fine-tuned: I
have to see how labels and properties could be added automatically:
music gender, year, etc. I have also defined a new type of link to be
able to play the content (*.m3u) via EMMS[1], and I have also added a new
action to helm-org-ql. Finally, in another section I am also storing
links to radio stations, TV, single songs (captured with org-capture),
etc. I have also found 'sacad' useful for downloading the cover art
(https://github.com/desbma/sacad).

This is my system for organizing my media files in Org. If anyone is
interested, I can expand on specific details. And here, a couple of
screenshots:

https://i.imgur.com/NKybgPV.png

https://i.imgur.com/DtfoyZl.jpg

[1]
#+begin_src emacs-lisp
  (org-link-set-parameters
   "url-media"
   :follow (lambda (path) (emms-play-url path))
   :face '(:foreground "chocolate" :weight bold :underline t))
#+end_src

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 7%]

* Re: Org and multimedia (tips?)
  2022-03-17 22:44  7% Org and multimedia (tips?) Juan Manuel Macías
@ 2022-03-18 14:40  6% ` Max Nikulin
  2022-03-19 11:13 10%   ` Juan Manuel Macías
  2022-05-05  1:14  5% ` TRS-80
  1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2022-03-18 14:40 UTC (permalink / raw)
  To: emacs-orgmode

On 18/03/2022 05:44, Juan Manuel Macías wrote:
> 
> What I do is quite simple and rudimentary. For example, I have all my
> music files stored on a hard drive on my Raspberry. As a media server I
> use GNUMP3d, which is pretty clunky and outdated, but it works fine and
> is very easy for me to administer. GNUMP3d serves a local web page with
> the list of titles and artists. I convert that web to an Org node using
> org-web-tools (https://github.com/alphapapa/org-web-tools), and some
> extra elisp to clean up inconsistencies and format everything so that
> each artist/title is a sub-tree. The process is not quite fine-tuned: I
> have to see how labels and properties could be added automatically:
> music gender, year, etc.
org-web-tools is an interesting project, but if you have access to files 
it should be easier to extract all meta information directly using e.g.

     exiftool -json file.mp3

or another tool suitable to particular format. It seems emms has 
interface to various tools.

P.S. You may try to adapt common LISP implementation of ID3 parser 
https://gigamonkeys.com/book/practical-an-id3-parser.html



^ permalink raw reply	[relevance 6%]

* Re: Move or rename a file in a link
  2022-03-10 14:58 10%   ` Juan Manuel Macías
@ 2022-03-18 18:52  6%     ` João Pedro de Amorim Paula
  2022-03-19 11:25  8%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: João Pedro de Amorim Paula @ 2022-03-18 18:52 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On 10 March 2022 14:58, Juan Manuel Macías <maciaschain@posteo.net> wrote:

> Hi João, Thanks for your comment.

Hello, Juan! I apologize for the delay on responding, I had some issues
with my e-mail account lately.

> Regarding attachments, do you mean org attachments or email attachments?
> Could you give an example of a use case?

I mean org attachments. I use org-attach extensively to store documents
with notes. So I'd have a heading like so

* Documents
:PROPERTIES:
:DIR: data/docs/
:END:

- [[Registration][attachment:registration.pdf]] :: My registration.

And say I'd like to rename the file. I would need to rename it inside
data/docs and I would also need to edit the link, so I would like to
have a way to do it automatically. I just got a computer back so I will
be trying to adapt what you did to work with org-attach, but if you
figure out a way to do it as well, please, let me know.

Regards,

-- 
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

^ permalink raw reply	[relevance 6%]

* Re: Org and multimedia (tips?)
  2022-03-18 14:40  6% ` Max Nikulin
@ 2022-03-19 11:13 10%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-19 11:13 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

Max Nikulin writes:

> org-web-tools is an interesting project, but if you have access to
> files it should be easier to extract all meta information directly
> using e.g.
>
>     exiftool -json file.mp3
>
> or another tool suitable to particular format. It seems emms has
> interface to various tools.
>
> P.S. You may try to adapt common LISP implementation of ID3 parser
> https://gigamonkeys.com/book/practical-an-id3-parser.html

Maxim, thanks a lot for the ideas. I take note. The reason for using
org-web-tools is that the web page that GNUMP3d serves is extremely
simple, with an alphabetical list of artists, titles, and links to the
.m3u to stream. The list is easily reusable in Org. In the end I managed
to write a function to create in each node a property drawer with
album title, date and artist, accessing each m3u and obtaining the
information with ffprobe (screenshot: https://i.imgur.com/1ALe4Ah.png).

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: Move or rename a file in a link
  2022-03-18 18:52  6%     ` João Pedro de Amorim Paula
@ 2022-03-19 11:25  8%       ` Juan Manuel Macías
  2022-03-22 15:30  5%         ` João Pedro de Amorim Paula
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-03-19 11:25 UTC (permalink / raw)
  To: João Pedro de Amorim Paula; +Cc: orgmode

Hi João,

João Pedro de Amorim Paula writes:

> I mean org attachments. I use org-attach extensively to store documents
> with notes. So I'd have a heading like so
>
> * Documents
> :PROPERTIES:
> :DIR: data/docs/
> :END:
>
> - [[Registration][attachment:registration.pdf]] :: My registration.
>
> And say I'd like to rename the file. I would need to rename it inside
> data/docs and I would also need to edit the link, so I would like to
> have a way to do it automatically. I just got a computer back so I will
> be trying to adapt what you did to work with org-attach, but if you
> figure out a way to do it as well, please, let me know.

I see. This is a new version that would also work with org attachment
links. I haven't tested it much and the function is a bit tricky, but I
think it works fine:

#+begin_src emacs-lisp
  (defun my-org-rename-link-file-at-point ()
    (interactive)
    (let* ((curr-dir (if (equal (org-element-property :type (org-element-context)) "attachment")
			 (concat (abbreviate-file-name (org-attach-dir)) "/")
		       (abbreviate-file-name default-directory)))
	   (current-path (if (equal (org-element-property :type (org-element-context)) "attachment")
			     (concat curr-dir (org-element-property :path (org-element-context)))
			   (org-element-property :path (org-element-context))))
	   (new-path (read-file-name "Rename file at point to: " current-path)))
      (rename-file current-path new-path)
      (message (concat "moved to: " new-path))
      (if (directory-name-p new-path)
	  (setq new-path (concat new-path (file-name-nondirectory current-path)))
	(setq new-path new-path))
      (if (equal (org-element-property :type (org-element-context)) "attachment")
	  (my-org-replace-link-file (file-name-nondirectory current-path)
				    (replace-regexp-in-string
				     curr-dir "" new-path))
	(my-org-replace-link-file current-path
				  (replace-regexp-in-string
				   curr-dir "" new-path)))))

  (defun my-org-replace-link-file (from to)
    (save-excursion
      (goto-char (point-min))
      (while (re-search-forward org-bracket-link-regexp nil t)
	(cond ((string-match-p (concat "attachment:" from) (match-string 1))
	       (replace-match (concat "[[attachment:" to "]]")))
	      ((string-match-p from (match-string 1))
	       (replace-match (concat "[[file:" to "]]")))))))
#+end_src

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: Move or rename a file in a link
  2022-03-19 11:25  8%       ` Juan Manuel Macías
@ 2022-03-22 15:30  5%         ` João Pedro de Amorim Paula
  0 siblings, 0 replies; 200+ results
From: João Pedro de Amorim Paula @ 2022-03-22 15:30 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

On 19 March 2022 11:25, Juan Manuel Macías <maciaschain@posteo.net> wrote:

> #+begin_src emacs-lisp
>   (defun my-org-rename-link-file-at-point ()
>     (interactive)
>     (let* ((curr-dir (if (equal (org-element-property :type (org-element-context)) "attachment")
> 			 (concat (abbreviate-file-name (org-attach-dir)) "/")
> 		       (abbreviate-file-name default-directory)))
> 	   (current-path (if (equal (org-element-property :type (org-element-context)) "attachment")
> 			     (concat curr-dir (org-element-property :path (org-element-context)))
> 			   (org-element-property :path (org-element-context))))
> 	   (new-path (read-file-name "Rename file at point to: " current-path)))
>       (rename-file current-path new-path)
>       (message (concat "moved to: " new-path))
>       (if (directory-name-p new-path)
> 	  (setq new-path (concat new-path (file-name-nondirectory current-path)))
> 	(setq new-path new-path))
>       (if (equal (org-element-property :type (org-element-context)) "attachment")
> 	  (my-org-replace-link-file (file-name-nondirectory current-path)
> 				    (replace-regexp-in-string
> 				     curr-dir "" new-path))
> 	(my-org-replace-link-file current-path
> 				  (replace-regexp-in-string
> 				   curr-dir "" new-path)))))
>
>   (defun my-org-replace-link-file (from to)
>     (save-excursion
>       (goto-char (point-min))
>       (while (re-search-forward org-bracket-link-regexp nil t)
> 	(cond ((string-match-p (concat "attachment:" from) (match-string 1))
> 	       (replace-match (concat "[[attachment:" to "]]")))
> 	      ((string-match-p from (match-string 1))
> 	       (replace-match (concat "[[file:" to "]]")))))))
> #+end_src

Just a couple of fixes and it seems to be working fine.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-rename-link.patch --]
[-- Type: text/x-patch, Size: 1012 bytes --]

diff -u a/org-rename-link.el b/org-rename-link.el

--- a/org-rename-link.el	2022-03-22 12:08:45.790727092 -0300
+++ b/org-rename-link.el	2022-03-22 12:25:31.500218923 -0300
@@ -23,8 +23,11 @@
 (defun my-org-replace-link-file (from to)
   (save-excursion
     (goto-char (point-min))
-    (while (re-search-forward org-bracket-link-regexp nil t)
-      (cond ((string-match-p (concat "attachment:" from) (match-string 1))
-             (replace-match (concat "[[attachment:" to "]]")))
-            ((string-match-p from (match-string 1))
-             (replace-match (concat "[[file:" to "]]")))))))
+    (while (re-search-forward org-link-bracket-re nil t)
+      (replace-match
+       (cond
+        ((string-match-p (format "^attachment:%s\\'" from) (match-string 1))
+         (format "attachment:%s" (file-name-nondirectory to)))
+        ((string-match-p (format "^file.*:%s\\'" from) (match-string 1))
+         (format "file:%s" to)))
+       nil nil nil 1))))

Diff finished.  Tue Mar 22 12:26:56 2022

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


All this patch does is to remove the directory name from the
=attachment:file.ext= -- given that the path is calculated by org-attach
--, and use the group 1 of the match string (as well as updating the use
of an obsolete variable), which corresponds to the actual link portion,
leaving the description unchanged.

Cordially,

-- 
João Pedro de A. Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

^ permalink raw reply	[relevance 5%]

* Re: TOC and latex memoir class
  @ 2022-04-02  7:21 10% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-02  7:21 UTC (permalink / raw)
  To: Steve Downey; +Cc: orgmode

Hi Steve,

Steve Downey writes:

> In order to place the table of contents without a section name
> "Contents" the memoir class uses \tableofcontents* rather than
> \tableofcontents.
> However, `org-latex-toc-command` is documented as:
>   "LaTeX command to set the table of contents, list of figures, etc.
> This command only applies to the table of contents generated with
> the toc:nil option, not to those generated with #+TOC keyword."
> Which is confusing in two ways, first that toc:nil doesn't generate a
> table of contents, and that it doesn't seem to provide any way of
> getting the string to be used? 
>
> As a workaround, I could use the latex command directly, but that
> means not having it available in, for example, an html export. 
>
> Is there a workaround I'm missing? 

One possible workaround would be to define a macro with a conditional:
if exporting to LaTeX, returns the string 'toc:nil'; otherwise, returns
'toc:t'. And the LaTeX command can be added via a export snippet.
Something like this:

#+MACRO: mytoc (eval (if (eq org-export-current-backend 'latex) "#+OPTIONS: toc:nil" "#+OPTIONS: toc:t"))

{{{mytoc}}}

@@latex:\tableofcontents*@@

* Heading 1

lorem ipsum dolor

* Heading 2

lorem ipsum dolor

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

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: when exporting latex how to set with in the includegraphics command
  @ 2022-04-03 10:19 10% ` Juan Manuel Macías
  2022-04-03 15:09  3%   ` Uwe Brauer
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-04-03 10:19 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode

Hi Uwe,

Uwe Brauer writes:

> But I would like a smaller width say 0.5, how can I achieve that?

#+ATTR_LaTeX: :float nil
#+ATTR_LaTeX: :width <any valid value>
#+CAPTION: El método del Trapecio  punto fijo vs PC
[[./diagram-trapfix-vs-trapfixpc-norigid.png]]

(You can add more options to the includegraphics optional argument with
:options attribute; for example, :options scale=.5, etc).

best regards,

Juan Manuel


^ permalink raw reply	[relevance 10%]

* Re: when exporting latex how to set with in the includegraphics command
  2022-04-03 10:19 10% ` Juan Manuel Macías
@ 2022-04-03 15:09  3%   ` Uwe Brauer
  0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2022-04-03 15:09 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode

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

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

Hi Juan Manuel
> Hi Uwe,
> Uwe Brauer writes:

>> But I would like a smaller width say 0.5, how can I achieve that?

> #+ATTR_LaTeX: :float nil
> #+ATTR_LaTeX: :width <any valid value>

Thanks very much, that was very helpful

Uwe 

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

^ permalink raw reply	[relevance 3%]

* Save Gnus attachments to Org using org-attach and helm-org-ql
@ 2022-04-10  8:49  9% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-10  8:49 UTC (permalink / raw)
  To: orgmode

Hi all,

I thought it wouldn't be a bad idea to be able to save attachments from
GNUS (current article) to any Org node, via org-attach. Since I use
helm-org-ql to quickly access the headlines of my org documents, it
occurred to me to write this action for helm-org-ql. I share it here in
case someone finds it useful.

Best regards,

Juan Manuel 

#+begin_src emacs-lisp
  (defun my-helm-org-ql/gnus-save-parts-to-org-attach (marker)
    (interactive)
    (switch-to-buffer (marker-buffer marker))
    (goto-char marker)
    (org-show-entry)
    (when (not (member "ATTACH" (org-element-property :tags (org-element-at-point))))
      (org-toggle-tag "ATTACH"))
    ;; create attach dir if not exits
    (let ((atch-dir (org-attach-dir t))
	  (art gnus-article-current))
      (gnus-summary-save-parts "." atch-dir art)))

  (with-eval-after-load 'helm-org-ql
    (add-to-list 'helm-org-ql-actions
		 '("Save attachments" . my-helm-org-ql/gnus-save-parts-to-org-attach) t))
#+end_src


^ permalink raw reply	[relevance 9%]

* #+latex_header blocks, or, managing lots of LaTeX headers
@ 2022-04-12  0:46  4% William Denton
  2022-04-12  2:51  0% ` Vikas Rawal
                   ` (2 more replies)
  0 siblings, 3 replies; 200+ results
From: William Denton @ 2022-04-12  0:46 UTC (permalink / raw)
  To: emacs-orgmode

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

I have another question related to managing a book I'm doing building for export 
to LaTeX:  what do people do for managing all of the headers?

I have about 30 #+latex_header lines in the project I'm working on, and I'm 
still just working on it as a basic article.  When I'm ready to do more 
formatting I'll use the memoir class and then there will be more commands.  I 
imagine some of you have huge headers with custom commands and more.

It would be great if there was a way to manage these lines as LaTeX, for example 
in a "#+begin_export latex" block, but as far as I can tell, there isn't a way 
(unless once again I overlooked something).

The idea came up about seven years ago, and Nicolas mentioned the possibility of 
a "#+begin_export latex :header t" implementation.

https://lists.gnu.org/archive/html/emacs-orgmode/2015-05/msg00538.html

It's possible to add a new class to the org-latex-classes variable, and in the 
documentation on it I see there are options ([NO-DEFAULT-PACKAGES], 
[NO-PACKAGES], [NO-EXTRA]) that allow one to trim away all the default headers. 
That makes it easy to take away, but not to add in lines I want, short of 
managing them in my init file.

What sorts of practices do people have for managing lots of LaTeX headers? 
Juan Manuel Macías, you mentioned something like this---literate programming in 
Org to export LaTeX source---may I ask how you do it?

Thanks,

Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

^ permalink raw reply	[relevance 4%]

* Re: #+latex_header blocks, or, managing lots of LaTeX headers
  2022-04-12  0:46  4% #+latex_header blocks, or, managing lots of LaTeX headers William Denton
@ 2022-04-12  2:51  0% ` Vikas Rawal
  2022-04-12  6:16  0% ` Tim Cross
  2022-04-12  8:55  8% ` Juan Manuel Macías
  2 siblings, 0 replies; 200+ results
From: Vikas Rawal @ 2022-04-12  2:51 UTC (permalink / raw)
  To: William Denton; +Cc: org-mode mailing list

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

For a major project like this, I would just put these in a separate file,
and include it using #+INCLUDE:

Vikas


On Tue, 12 Apr 2022 at 06:37, William Denton <wtd@pobox.com> wrote:

> I have another question related to managing a book I'm doing building for
> export
> to LaTeX:  what do people do for managing all of the headers?
>
> I have about 30 #+latex_header lines in the project I'm working on, and
> I'm
> still just working on it as a basic article.  When I'm ready to do more
> formatting I'll use the memoir class and then there will be more
> commands.  I
> imagine some of you have huge headers with custom commands and more.
>
> It would be great if there was a way to manage these lines as LaTeX, for
> example
> in a "#+begin_export latex" block, but as far as I can tell, there isn't a
> way
> (unless once again I overlooked something).
>
> The idea came up about seven years ago, and Nicolas mentioned the
> possibility of
> a "#+begin_export latex :header t" implementation.
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2015-05/msg00538.html
>
> It's possible to add a new class to the org-latex-classes variable, and in
> the
> documentation on it I see there are options ([NO-DEFAULT-PACKAGES],
> [NO-PACKAGES], [NO-EXTRA]) that allow one to trim away all the default
> headers.
> That makes it easy to take away, but not to add in lines I want, short of
> managing them in my init file.
>
> What sorts of practices do people have for managing lots of LaTeX headers?
> Juan Manuel Macías, you mentioned something like this---literate
> programming in
> Org to export LaTeX source---may I ask how you do it?
>
> Thanks,
>
> Bill
>
> --
> William Denton
> https://www.miskatonic.org/
> Librarian, artist and licensed private investigator.
> Toronto, Canada

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

^ permalink raw reply	[relevance 0%]

* Re: #+latex_header blocks, or, managing lots of LaTeX headers
  2022-04-12  0:46  4% #+latex_header blocks, or, managing lots of LaTeX headers William Denton
  2022-04-12  2:51  0% ` Vikas Rawal
@ 2022-04-12  6:16  0% ` Tim Cross
  2022-04-12  8:55  8% ` Juan Manuel Macías
  2 siblings, 0 replies; 200+ results
From: Tim Cross @ 2022-04-12  6:16 UTC (permalink / raw)
  To: William Denton; +Cc: emacs-orgmode


William Denton <wtd@pobox.com> writes:

> I have another question related to managing a book I'm doing building for export to LaTeX:
> what do people do for managing all of the headers?
>

I only use the #+latex_headers or #+latext-headers-extra lines for 'one
off' type documents. If I'm going to be writing lots of documents where
those packages are needed, I define a new org-latex-classes entry.

> It's possible to add a new class to the org-latex-classes variable, and in the documentation on
> it I see there are options ([NO-DEFAULT-PACKAGES], [NO-PACKAGES], [NO-EXTRA]) that allow one to
> trim away all the default headers. That makes it easy to take away, but not to add in lines I
> want, short of managing them in my init file.

The org-latex-classes 'placeholder' macros allow you to add or remove
the headers defined in either the default-packages or packages alist or
headers added via latex_headers/latex_headers_extra. However, the point
to note is that this 'value' is just a string, so you can just put in
exactly what you want - you don't have to use the placeholder macros
(though I almost always do - at least the [default-packages] macro, but
usually the [packages] one as well). The value isn't just restricted to
\usepackage lines either - you can put anything there which makes sense
in the latgex header.

>
> What sorts of practices do people have for managing lots of LaTeX headers? Juan Manuel Macías,
> you mentioned something like this---literate programming in Org to export LaTeX source---may I
> ask how you do it?
>

If I find myself using lots of #+latex_headers lines, this tells me
either

1. I need to update/add to the packages alist variable. This is
especially likely if I'm adding the same headers to every document. Just
add it to the packages alist. I tend to leave the default-packages alist
alone.

2. There is a specific 'style' of document I write often and all
documents of this style have the same additional headers. For this, I
create a new entry in org-latex-classes.

I think adding headers via #+latex_headers and #+latext_headers_extra
should be avoided as much as possible. It is a great escape hatch or for
doing 'on-offs', but not the right approach for doing something like
writing a book.

Consider the situation where you have been adding headers to load
language support or a particular code listing package or whatever. You
writing a book and it will have many org files (perhaps one per
chapter). You add these #+latex_header lines to add the packages. Later,
you find the listing package isn't suitable or you need to modify the
language encoding - now you have to edit every org file which makes up
the book.

Alternatively, you define a new org-latex-classes entry call 'my-book'
and use that to add the language encoding and code listing packages
(along with some other 'tweaks' you typically put in the header, maybe
even add a few custom commands etc). Now when you find it necessary to
change the language encoding, code listing package or whatever, you just
have that one definition to change and only need to edit one file.


^ permalink raw reply	[relevance 0%]

* Re: #+latex_header blocks, or, managing lots of LaTeX headers
  2022-04-12  0:46  4% #+latex_header blocks, or, managing lots of LaTeX headers William Denton
  2022-04-12  2:51  0% ` Vikas Rawal
  2022-04-12  6:16  0% ` Tim Cross
@ 2022-04-12  8:55  8% ` Juan Manuel Macías
  2 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-12  8:55 UTC (permalink / raw)
  To: William Denton; +Cc: orgmode

Hi William,

William Denton writes:

> What sorts of practices do people have for managing lots of LaTeX
> headers? Juan Manuel Macías, you mentioned something like
> this---literate programming in Org to export LaTeX source---may I ask
> how you do it?

When it comes to a large project, for example the typesetting of a book,
I usually generate all the configuration for LaTeX in a *.tex document or
a *.sty document from Org, using literate programming[1]. I include there all
the LaTeX packages I use, their configuration, my own LaTeX or Lua code
(because I use LuaTeX to compile), etc. Here is a screenshot of a  part of
the configuration I wrote for the Hispanic Dictionary of the Classical
Tradition:

https://i.imgur.com/fwonZtT.png

I also have an 'empty' class added to the org-latex-classes list, and then
load my LaTeX configuration via \input. When it comes to large books I
also use org-publish, which makes it easier for me to work with complex
projects and multi-part/chapter books.

Another possibility, to avoid adding many lines with 'LaTeX_Header:', is
to use blocks and the noweb keyword. For example: you can create a
non-exportable node in your document, and put all the necessary
configuration there. You include all the LaTeX preamble in a block:

* Configuration           :noexport:

#+NAME: preamble
#+begin_src latex :exports none
a lot of LaTeX code
#+end_src

And in another block you add this:

#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <<preamble>>
#+end_src

(in this thread you can find an org document attached with this procedure:
https://list.orgmode.org/87sfwvlp56.fsf@posteo.net/)
----------------------------

[1] In fact, Org is much more powerful and simpler for doing these
things than the docstript suite itself that is 'officially' used in the
(La)TeX ecosystem to generate packages code and documentation:
https://ctan.org/pkg/docstrip?lang=en

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: [PATCH] org-element-export-snippet-parser: Fix snippets without ending @@
  @ 2022-04-16 10:46 10% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-16 10:46 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Our current parser recognises the opening "@@html:" as a standalone
> snippet.
>
> Unless I misunderstand something, it is not intentional.
>
> The fix is attached.

This fix makes a lot of sense to me. I've always been intrigued by this
'strange' behavior of html export snippets. Of course, the main danger of
this unintentional behavior is error propagation. I remember seeing it
on a few sites, like here: https://emacs.stackexchange.com/a/30470

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: latex block tikz to svg
    2022-01-25 23:24  6%   ` Edouard Debry
@ 2022-04-18 13:23  4%   ` Edouard Debry
  1 sibling, 0 replies; 200+ results
From: Edouard Debry @ 2022-04-18 13:23 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode


Hi,

I finally found a way to make the following example work

<===========================================================>
#+HEADER: :file test1.svg
#+HEADER: :exports results
#+HEADER: :results output silent graphics file
#+HEADER: :headers '("\\usepackage{tikz}")
#+begin_src latex
\begin{tikzpicture}
\draw[->] (-3,0) -- (-2,0) arc[radius=0.5cm,start angle=-180,end angle=0] (-1,0) -- (1,0) arc[radius=0.5cm,start angle=180,end angle=0] (2,0) -- (3,0);
\filldraw (-1.5,0) circle[radius=1mm];
\filldraw (1.5,0) circle[radius=3mm];
\end{tikzpicture}
#+end_src
<===========================================================>

In file ob-latex.el, I commented out the lines beginning with ((string=
"svg" extension) :
	 ;; ((string= "svg" extension)
	 ;;  (with-temp-file tex-file
	 ;;    (insert (concat (funcall org-babel-latex-preamble params)
	 ;;        	    (mapconcat #'identity headers "\n")
	 ;;        	    (funcall org-babel-latex-begin-env params)
	 ;;        	    body
	 ;;        	    (funcall org-babel-latex-end-env params))))
	 ;;  (let ((tmp-pdf (org-babel-latex-tex-to-pdf tex-file)))
         ;;    (let* ((log-buf (get-buffer-create "*Org Babel LaTeX Output*"))
         ;;           (err-msg "org babel latex failed")
         ;;           (img-out (org-compile-file
	 ;;                     tmp-pdf
         ;;                     (list org-babel-latex-pdf-svg-process)
         ;;                     extension err-msg log-buf)))
         ;;      (shell-command (format "mv %s %s" img-out out-file)))))

This part is responsible for the previous example to fail. What actually
breaks the svg production is the latex preamble. "pdflatex" fails itself
to produce a valid pdf file.


After that, I changed
((and (string= "html" extension)
	       (executable-find org-babel-latex-htlatex))

into

((and (or (string= "html" extension) (string= "svg" extension))
	       (executable-find org-babel-latex-htlatex))

Then, previous example, is compiled no more by "pdflatex" but by
"htlatex", this latter is able to produce svg directly.

I hope I do not introduce any side effects in doing so. There are several ways
to produce svg :
- pdflatex + inkscape (default with current org implementation)
- latex + dvisvgm
- pdflatex + pdf2svg
- htlatex (my choice above)

Ideally, all ways could be implemented and orgmode's user should choose
which way to use through a header parameter. As far as I could
understand, "htlatex" is the faster (direct) and cleaner way to produce
svg, but it may lack some advanced features, which is probably why, at the 
moment, the default way is through pdf generation.

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

> Hi Edouard,
>
> Edouard Debry writes:
>
>> I would like to find a way to generate svg images from latex src blocks
>> (using tikz) which works and is compatible with default orgmode settings
>> for latex export (at least does not break it)
>>
>> Did you experience such issues ? do you have some workings settings and
>> examples ? I googled several times "org latex block tikz svg", but it is
>> difficult to guess how relevant are the elements found, some of them
>> seems quiet outdated. Hence my question on this mailing list
>
> I've done some quick tests with your example block. I don't know if I'm
> wrong, but I think the problem is on line 27 of `org-babel-execute:latex':
>
> ((string= "svg" extension)
>
> I don't know if this should be considered an Org bug, but it's clear
> that if the svg extension is detected in :file, the ':imagemagick yes'
> option is ignored, and a type of preamble is generated that fails in
> pgfsysdriver when compiling the temp tex document:
>
> \documentclass[preview]{standalone}
> \def\pgfsysdriver{pgfsys-tex4ht.def}
>
> If I replace the above line with this conditional:
>
> ((and (string= "svg" extension) (not imagemagick))
>
> then the imagemagick option is taken into account: it creates correctly
> the pdf and then converts it to svg with 'convert' imagemagick program.
> I did have to remove this line though:
>
> #+HEADER: :imoutoptions -geometry 400 :iminoptions -density 600
>
> otherwise, the conversion produced a dark image.
>
> Best regards,
>
> Juan Manuel 


^ permalink raw reply	[relevance 4%]

* [tip] Org speed commands improved
@ 2022-04-26 14:00  9% Juan Manuel Macías
  2022-04-27  4:20  6% ` Ihor Radchenko
  2022-04-27 16:30  6% ` Daniel Fleischer
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-26 14:00 UTC (permalink / raw)
  To: orgmode

Hi all,

Org speed commands are a major productivity boost and I love them.
Lately it has occurred to me to make some modifications with the
following configuration, which I share here in case someone wants to try
it. The idea is that Org speed commands are activated anywhere in the
header (not just at the beginning of the line) *or* when point is at the
very beginning of the buffer. This, in my opinion, improves the
navigation speed:

#+begin_src emacs-lisp
  (setq org-use-speed-commands
        (lambda () (or (eq (point) 1)
                       (org-in-regexp "^\\*+\s+.+"))))
#+end_src

This also serves as a kind of write protection for the header titles. To
be able to edit them, we can use this function:

#+begin_src emacs-lisp
  (defun my-org-toggle-speed-commands ()
    (interactive)
    (if org-use-speed-commands
        (progn (setq org-use-speed-commands nil)
               (message "speed-commands off"))
      (setq org-use-speed-commands
            (lambda () (or (eq (point) 1)
                           (org-in-regexp "^\\*+\s+.+"))))
      (message "speed-commands on")))

  (with-eval-after-load 'org
    (define-key org-mode-map (kbd "M-i") 'my-org-toggle-speed-commands))
#+end_src

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 9%]

* Re: [tip] Org speed commands improved
  2022-04-26 14:00  9% [tip] Org speed commands improved Juan Manuel Macías
@ 2022-04-27  4:20  6% ` Ihor Radchenko
  2022-04-27  5:37  0%   ` Tim Cross
  2022-04-27  7:08  9%   ` Juan Manuel Macías
  2022-04-27 16:30  6% ` Daniel Fleischer
  1 sibling, 2 replies; 200+ results
From: Ihor Radchenko @ 2022-04-27  4:20 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> Org speed commands are a major productivity boost and I love them.
> Lately it has occurred to me to make some modifications with the
> following configuration, which I share here in case someone wants to try
> it. The idea is that Org speed commands are activated anywhere in the
> header (not just at the beginning of the line) *or* when point is at the
> very beginning of the buffer. This, in my opinion, improves the
> navigation speed:
> ...
> This also serves as a kind of write protection for the header titles. To
> be able to edit them, we can use this function:

If you are going this far with speed commands, you might as well switch
to modal editing. What you are describing is basically a modal command
map with ability to switch to insert map.

Best,
Ihor


^ permalink raw reply	[relevance 6%]

* Re: [tip] Org speed commands improved
  2022-04-27  4:20  6% ` Ihor Radchenko
@ 2022-04-27  5:37  0%   ` Tim Cross
  2022-04-27  7:08  9%   ` Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: Tim Cross @ 2022-04-27  5:37 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Juan Manuel Macías, orgmode


Ihor Radchenko <yantar92@gmail.com> writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Org speed commands are a major productivity boost and I love them.
>> Lately it has occurred to me to make some modifications with the
>> following configuration, which I share here in case someone wants to try
>> it. The idea is that Org speed commands are activated anywhere in the
>> header (not just at the beginning of the line) *or* when point is at the
>> very beginning of the buffer. This, in my opinion, improves the
>> navigation speed:
>> ...
>> This also serves as a kind of write protection for the header titles. To
>> be able to edit them, we can use this function:
>
> If you are going this far with speed commands, you might as well switch
> to modal editing. What you are describing is basically a modal command
> map with ability to switch to insert map.
>

Funny - as I read Juan's post, as an evil user, that was exactly my
thought. I've never looked at the org speed commands, but as I read the
post, I thought "that looks like what I have with evil mode"



^ permalink raw reply	[relevance 0%]

* Re: [tip] Org speed commands improved
  2022-04-27  4:20  6% ` Ihor Radchenko
  2022-04-27  5:37  0%   ` Tim Cross
@ 2022-04-27  7:08  9%   ` Juan Manuel Macías
  2022-05-04 22:12  6%     ` TRS-80
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-04-27  7:08 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Hi Ihor,

Ihor Radchenko writes:

> If you are going this far with speed commands, you might as well switch
> to modal editing. What you are describing is basically a modal command
> map with ability to switch to insert map.

I'm not a fan of modal editing, rather the opposite. But in this
particular case I have found that I spend very little time editing the
raw content of the headers, once I set it. I spend more time editing the
'meta-content': TODO states, properties, tags, refile, attached folders,
etc. And that with the speed commands can be achieved in a very agile
way, so that a small dose of controlled modal editing and reduced only
to the header, maybe it's worth it :-) If the speed commands were also
activated in the content of the sections, here we would have a real
modal editing, and that (in my case) would not be comfortable.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: [tip] Org speed commands improved
  2022-04-26 14:00  9% [tip] Org speed commands improved Juan Manuel Macías
  2022-04-27  4:20  6% ` Ihor Radchenko
@ 2022-04-27 16:30  6% ` Daniel Fleischer
  1 sibling, 0 replies; 200+ results
From: Daniel Fleischer @ 2022-04-27 16:30 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías [2022-04-26 Tue 14:00] wrote:

> Org speed commands are a major productivity boost and I love them.
> Lately it has occurred to me to make some modifications with the
> following configuration, which I share here in case someone wants to try
> it. The idea is that Org speed commands are activated anywhere in the
> header (not just at the beginning of the line) *or* when point is at the
> very beginning of the buffer. This, in my opinion, improves the
> navigation speed:

Very nice idea; I'll give it a try, thanks!

-- 

Daniel Fleischer


^ permalink raw reply	[relevance 6%]

* Org as a workspace (an impromptu reflection)
@ 2022-04-29 15:03  7% Juan Manuel Macías
  2022-04-29 23:46  6% ` Matt
  2022-05-02 19:17  6% ` Nick Dokos
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-29 15:03 UTC (permalink / raw)
  To: orgmode

Hi all,

Since I use Org Mode I have been noticing a gradual change in the way I
work with a computer (as a simple user). It is not something consciously
sought, but I have to say that I see it as a positive evolution. I've
always been used to (or rather resigned to) the typical Unix
directory/file scheme: everything must be a file and everything must be
stored in a directory. When one has many and varied interests and tasks,
and manages a wide variety of files and folders, it is certainly hard to
maintain order and 'digital hygiene' within that scheme. Before using
Gnu Emacs as a shell and as a desktop environment, I used KDE and Gnome for
quite a while. The indexers and file search tools in these environments
(especially the GnomeShell one, tracker) were somewhat helpful in
keeping things tidy and close at hand. But, at the end of the day, the
directory/file scheme was always present.

With Org something curious has happened. I've gotten used to working
around nodes (regardless of what documents those nodes are in), rather
than around folders or files. Little by little, a kind of virtual world
of ideas, objects, etc., all intertwined with each other, is being
built. What amazes me about Org is that all of this is tremendously
transparent and simple. I'm not saying that the detachment of the
directory/file schema is complete: directories and files are there,
actually, but at least they don't show up when working. It is somewhat
akin to being in a play, where there is a suspension of disbelief.

Of course, there are tools that I find indispensable. Helm-org-ql, for
example, is what I use to nimbly navigate that virtual world of nodes. I
also make heavy and obsessive use of org-attach and org-capture (I
barely use the classic 'Documents', 'Images', 'Videos', 'Music', etc.
style directories, but everything is stored in folders associated with
nodes). And since I've started using org-transclusion, a new dimension
has been opened to that virtuality that I mentioned before. Sometimes I
wonder if this isn't a working style similar to that of the old Lisp
machines, a subject I find exciting but know little about, so I
apologize if that statement sounds too ignorant ;-).

I don't know if anyone has had a similar experience...

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 7%]

* Re: Org as a workspace (an impromptu reflection)
  2022-04-29 15:03  7% Org as a workspace (an impromptu reflection) Juan Manuel Macías
@ 2022-04-29 23:46  6% ` Matt
  2022-05-02 19:17  6% ` Nick Dokos
  1 sibling, 0 replies; 200+ results
From: Matt @ 2022-04-29 23:46 UTC (permalink / raw)
  To: "Juan Manuel Macías"; +Cc: orgmode


 ---- On Fri, 29 Apr 2022 11:03:55 -0400 Juan Manuel Macías <maciaschain@posteo.net> wrote ----
 > I don't know if anyone has had a similar experience...

I tell people that Emacs changed my life. I feel it's that profound. My story is different from yours, yet similar in that it started with Org.   I love that it  has this affect on people.  It brings a smile to my face. This really is a great community.  Thanks for sharing your experience. :)


^ permalink raw reply	[relevance 6%]

* [PATCH] speed commands: error message when a key is not associated with a command
@ 2022-04-30 11:25  9% Juan Manuel Macías
  2022-04-30 13:06  6% ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-04-30 11:25 UTC (permalink / raw)
  To: orgmode

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

Hi,

If we have speed commands activated and we type (by mistake) a character
not associated with a command, the letter is printed at point. I think a
more appropriate behavior would be:

- key associated with a command: the command is activated

- key not associated with a command: an error message is displayed.

Attached a patch with that modification.

Best regards,

Juan Manuel 


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-org-keys.el-error-message-when-speed-command-is.patch --]
[-- Type: text/x-patch, Size: 1489 bytes --]

From fd380f41420aef9bc91baede9d4cd2cb7eadee0a Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 30 Apr 2022 13:00:02 +0200
Subject: [PATCH] lisp/org-keys.el: error message when speed command is not
 defined

* (org-speed-command-activate): If a letter is not associated with a
command, an error message is displayed instead of typing the letter.
---
 lisp/org-keys.el | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 782ffa871..a850abb4f 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -835,12 +835,14 @@ See `org-speed-commands' for configuring them."
   (when (or (and (bolp) (looking-at org-outline-regexp))
 	    (and (functionp org-use-speed-commands)
 		 (funcall org-use-speed-commands)))
-    (cdr (assoc keys
-                ;; FIXME: don't check `org-speed-commands-user' past 9.6
-                (if (boundp 'org-speed-commands-user)
-                    (append org-speed-commands
-                            org-speed-commands-user)
-                  org-speed-commands)))))
+    (let ((defined (cdr (assoc keys
+			       ;; FIXME: don't check `org-speed-commands-user' past 9.6
+			       (if (boundp 'org-speed-commands-user)
+				   (append org-speed-commands
+					   org-speed-commands-user)
+				 org-speed-commands)))))
+      (if defined defined
+	(error "Speed command not defined: \"h\" for help")))))
 
 \f
 ;;; Babel speed keys
-- 
2.36.0


^ permalink raw reply related	[relevance 9%]

* Re: [BUG] Exporting italic link with bang inside to html fails to parse the link [9.5.2 (N/A @ /gnu/store/89yvbijwnvsbpa5h33mvbgh1gy9w30n2-emacs-org-9.5.2/share/emacs/site-lisp/org-9.5.2/)]
  @ 2022-04-30 11:47  5%   ` Max Nikulin
  0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-04-30 11:47 UTC (permalink / raw)
  To: Ihor Radchenko, Dr. Arne Babenhauserheide; +Cc: emacs-orgmode

On 30/04/2022 16:37, Ihor Radchenko wrote:
> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
> 
>> To reproduce:
>>
>> - create an org-file with the following content:
>> /Foo [[https://taz.de/!5843294/][link with a bang]]/
>> - M-x org-html-export-to-html
>>
>> Expected: The HTML-file contains an italic link named "link with a bang".
>>
>> Actual: The HTML-file contains a broken link with only the domain:
>> <i>Foo [[<a href="https://taz.de">https://taz.de</a></i>!5843294/][link with a bang]]/</p>
> 
> Confirmed.

Nicolas clearly expressed that it is a feature of the Org parser though.

Moreover, this is a duplicate of another item already tracked on 
updates.orgmode.org:

2021-09-03  5:17 Dr. Arne Babenhauserheide Bug: PDF Export of Link fails
https://list.orgmode.org/87pmtqp79s.fsf@web.de/T/#u

The following markup should be used instead:

     /Foo/ [[https://taz.de/!5843294/][/link with a bang/]]

> To force Org mode not treat internal /! as italics ending, you can
> insert a zero-width space before "/": <zero width space>/!

Unfortunately It requires an additional export filter to remove zero 
width spaces.

> On the other hand, the example link could be inserted using
> org-insert-link.
> 
> If one does the following:
> 1. emacs -Q /tmp/test.org
> 2. Type "/Begin italic "
> 3. C-c C-l https://taz.de/!5843294/ <RET> <test> <RET>
> 4. The inserted text is not a link because the problematic /! is not
>     fixed automatically.
> 
> I consider the above to be at least a bug in org-insert-link.

Timothy suggested to fix `org-insert-link' somehow in than thread.

P.S. Actually I like behavior of pandoc

    printf '%s' '/Foo [[https://taz.de/!5843294/][link with a bang]]/' |
        pandoc -f org -t html

    <p><em>Foo <a href="https://taz.de/!5843294/">link with a 
bang</a></em></p>

Juan Manuel Macías to emacs-orgmode. Pandoc and nested emhases. Fri, 18 
Feb 2022 00:47:18 +0000. https://list.orgmode.org/87sfshgfvt.fsf@posteo.net


^ permalink raw reply	[relevance 5%]

* Re: [PATCH] speed commands: error message when a key is not associated with a command
  2022-04-30 11:25  9% [PATCH] speed commands: error message when a key is not associated with a command Juan Manuel Macías
@ 2022-04-30 13:06  6% ` Ihor Radchenko
  2022-04-30 14:41  8%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-04-30 13:06 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> If we have speed commands activated and we type (by mistake) a character
> not associated with a command, the letter is printed at point. I think a
> more appropriate behavior would be:
>
> - key associated with a command: the command is activated
>
> - key not associated with a command: an error message is displayed.

The idea is not bad, but I doubt that it can be implemented cleanly
given the current speed commands design.

> * (org-speed-command-activate): If a letter is not associated with a
> command, an error message is displayed instead of typing the letter.

Note that speed commands are not only decided by
org-speed-command-activate. Any function in org-speed-command-hook can
trigger speed command. Throwing an error in org-speed-command-activate
can potentially shadow other functions in the hook.

Best,
Ihor



^ permalink raw reply	[relevance 6%]

* Re: [PATCH] speed commands: error message when a key is not associated with a command
  2022-04-30 13:06  6% ` Ihor Radchenko
@ 2022-04-30 14:41  8%   ` Juan Manuel Macías
  2022-04-30 19:39  8%     ` Juan Manuel Macías
  2022-05-01  4:01  5%     ` Ihor Radchenko
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-30 14:41 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Note that speed commands are not only decided by
> org-speed-command-activate. Any function in org-speed-command-hook can
> trigger speed command. Throwing an error in org-speed-command-activate
> can potentially shadow other functions in the hook.

Ah, I see... I had not taken into account what you mention.

But, if I have understood correctly how this hook works, each associated
function has its "independence", right? I mean, if I have
org-speed-command-activate and org-babel-speed-command-activate
associated to this hook, and I bind the "K" key to an action in
org-babel-key-bindings, but that key does not is associated with any
action in org-speed-commands, then the error message would only be
displayed in the proper context, that is, if I hit K at the beginning of
the headline or any location defined for org-use-speed-commands.

Another possibility I can think of is, instead of returning an error
message: just do nothing when a wrong key is pressed. Something, maybe,
like this (I suppose that the same should be done in each function added
to the hook):

...
(let ((defined (cdr (assoc keys
                               ;; FIXME: don't check `org-speed-commands-user' past 9.6
                               (if (boundp 'org-speed-commands-user)
                                   (append org-speed-commands
                                           org-speed-commands-user)
                                 org-speed-commands)))))
      (if defined defined
        'ignore))))

I don't know if this would avoid unexpected results...

what do you think?

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 8%]

* Re: [PATCH] speed commands: error message when a key is not associated with a command
  2022-04-30 14:41  8%   ` Juan Manuel Macías
@ 2022-04-30 19:39  8%     ` Juan Manuel Macías
  2022-05-01  4:01  5%     ` Ihor Radchenko
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-30 19:39 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

> Ihor Radchenko writes:
>
>> Note that speed commands are not only decided by
>> org-speed-command-activate. Any function in org-speed-command-hook can
>> trigger speed command. Throwing an error in org-speed-command-activate
>> can potentially shadow other functions in the hook.

This other, more general solution has also occurred to me, although I
don't know if it's too tricky :-). The idea is to define an
org-speed-command-strict-hook. Something like this (I haven't tested it
much), and probably have its drawbacks:

#+begin_src emacs-lisp
  (defcustom org-speed-command-strict-hook
    nil
    "TODO"
    :group 'org-structure
    :version "24.1"
    :type 'hook)

  (defun org-speed-command-strict-function (_)
    (pcase (run-hook-with-args-until-success 'org-speed-command-strict-hook _)
      ('nil (error "Command not defined: \"?\" for help"))
      (symbol (run-hook-with-args-until-success 'org-speed-command-strict-hook _))))

  ;; no strict speed commands (default values):

    ;; org-speed-command-strict-hook: nil
    ;; org-speed-command-hook: (org-speed-command-activate org-babel-speed-command-activate)

 ;; when strict speed commands:

  (setq org-speed-command-strict-hook '(org-speed-command-activate org-babel-speed-command-activate))

  (setq org-speed-command-hook '(org-speed-command-strict-function))

  (defun my-org-toggle-speed-commands ()
    (interactive)
    (if org-use-speed-commands
	(progn
	  (setq org-use-speed-commands-on org-use-speed-commands)
	  (setq org-use-speed-commands nil)
	  (message "speed commands off"))
      (setq org-use-speed-commands org-use-speed-commands-on)
      (message "speed commands on")))
#+end_src

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: [PATCH] speed commands: error message when a key is not associated with a command
  2022-04-30 14:41  8%   ` Juan Manuel Macías
  2022-04-30 19:39  8%     ` Juan Manuel Macías
@ 2022-05-01  4:01  5%     ` Ihor Radchenko
  2022-05-01 11:00  9%       ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-01  4:01 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> Ihor Radchenko writes:
>
>> Note that speed commands are not only decided by
>> org-speed-command-activate. Any function in org-speed-command-hook can
>> trigger speed command. Throwing an error in org-speed-command-activate
>> can potentially shadow other functions in the hook.
>
> Ah, I see... I had not taken into account what you mention.
>
> But, if I have understood correctly how this hook works, each associated
> function has its "independence", right? I mean, if I have
> org-speed-command-activate and org-babel-speed-command-activate
> associated to this hook, and I bind the "K" key to an action in
> org-babel-key-bindings, but that key does not is associated with any
> action in org-speed-commands, then the error message would only be
> displayed in the proper context, that is, if I hit K at the beginning of
> the headline or any location defined for org-use-speed-commands.

You are mostly correct, with one potential caveat.
Consider a user who wants to define extra speed command that should run
at the beginning of level 1 headlines. This context also matches the
context of org-babel-speed-command-activate and your proposed patch will
make it harder for the user to achieve the described behaviour.

On the other hand, the user could simply add to front of the
org-speed-command-hook given that blocking behaviour of
org-babel-speed-command-activate is well-documented.

> Another possibility I can think of is, instead of returning an error
> message: just do nothing when a wrong key is pressed. Something, maybe,
> like this (I suppose that the same should be done in each function added
> to the hook):

This would not solve the problem of shadowing.
It may be better idea to provide a custom variable controlling
org-babel-speed-command-activate: do nothing or throw an error.
This custom variable should also be described in the docstring of
org-speed-command-hook to warn about potential shadowing.

To summarise, your idea will be reasonable if:
1. The new behaviour can be customized
2. The new behaviour is documented in org-speed-command-hook

Best,
Ihor



^ permalink raw reply	[relevance 5%]

* Re: [PATCH] speed commands: error message when a key is not associated with a command
  2022-05-01  4:01  5%     ` Ihor Radchenko
@ 2022-05-01 11:00  9%       ` Juan Manuel Macías
  2022-05-02  3:31  6%         ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-01 11:00 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> This would not solve the problem of shadowing.
> It may be better idea to provide a custom variable controlling
> org-babel-speed-command-activate: do nothing or throw an error.
> This custom variable should also be described in the docstring of
> org-speed-command-hook to warn about potential shadowing.
>
> To summarise, your idea will be reasonable if:
> 1. The new behaviour can be customized
> 2. The new behaviour is documented in org-speed-command-hook

Ok, I agree that this is the most reasonable direction. What do you
think about the idea that I outlined in the last post of this thread
(https://list.orgmode.org/87v8uqmkc0.fsf@posteo.net/)?: it consists in
defining a new hook (by default with value nil) where the user can store
those functions that he wants to have a 'strict' behavior: some functions
or all. And then the user should add the
org-speed-command-strict-function to org-speed-command-hook.

If this idea sounds too hacky, I think a defcustom for
org-babel-speed-command-activate, as you suggest, might suffice.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: [PATCH] speed commands: error message when a key is not associated with a command
  2022-05-01 11:00  9%       ` Juan Manuel Macías
@ 2022-05-02  3:31  6%         ` Ihor Radchenko
  2022-05-03 23:08  8%           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-02  3:31 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> Ok, I agree that this is the most reasonable direction. What do you
> think about the idea that I outlined in the last post of this thread
> (https://list.orgmode.org/87v8uqmkc0.fsf@posteo.net/)?: it consists in
> defining a new hook (by default with value nil) where the user can store
> those functions that he wants to have a 'strict' behavior: some functions
> or all. And then the user should add the
> org-speed-command-strict-function to org-speed-command-hook.
>
> If this idea sounds too hacky, I think a defcustom for
> org-babel-speed-command-activate, as you suggest, might suffice.

It is more complex and I do not see a clear benefit of introducing a
whole new hook. It would only be useful for people who define a large
number of extra speed command handlers.

Disclaimer: I do not use speed commands myself, so my opinion is
somewhat theoretical. If other users who are actively using speed
command hook have something to say, I'd encourage them to join the
discussion.

Best,
Ihor


^ permalink raw reply	[relevance 6%]

* Re: Org as a workspace (an impromptu reflection)
  2022-04-29 15:03  7% Org as a workspace (an impromptu reflection) Juan Manuel Macías
  2022-04-29 23:46  6% ` Matt
@ 2022-05-02 19:17  6% ` Nick Dokos
  2022-05-03 23:41 10%   ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Nick Dokos @ 2022-05-02 19:17 UTC (permalink / raw)
  To: emacs-orgmode

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

> With Org something curious has happened. I've gotten used to working
> around nodes (regardless of what documents those nodes are in), rather
> than around folders or files. Little by little, a kind of virtual world
> of ideas, objects, etc., all intertwined with each other, is being
> built.

From my vantage point (of ignorance about it :-) ), this sounds like
org-roam to me: https://www.orgroam.com/

-- 
Nick

"There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler



^ permalink raw reply	[relevance 6%]

* Re: [PATCH] speed commands: error message when a key is not associated with a command
  2022-05-02  3:31  6%         ` Ihor Radchenko
@ 2022-05-03 23:08  8%           ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-03 23:08 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> It is more complex and I do not see a clear benefit of introducing a
> whole new hook. It would only be useful for people who define a large
> number of extra speed command handlers.

Yes, I agree. Also I'm afraid that this idea of mine added a drawback as
a bonus track: it would be necessary to modify all the functions that
activate the speed commands because, otherwise, it would return an error
anywhere outside the activation contexts. Precisely because of this:

    (pcase (run-hook-with-args-until-success 'org-speed-command-strict-hook _)
      ('nil (error "Command not defined: \"?\" for help"))
      (symbol (run-hook-with-args-until-success
      'org-speed-command-strict-hook _)))

And I suppose that the functions should consist of a conditional of the
type: "if the context is given -> activate the speed commands, otherwise
-> self-insert-command". Or something like that. Too hacky.

On the other hand, I now seriously doubt whether a patch would be worth
it, even if a defcustom was added. I think you're also right about what
you said at the beginning: considering how speed commands are designed,
it's hard to implement a clean, general solution. I think I'm going to
leave this patch in the fridge for now, though I also encourage other
potential users of speed commands to join the discussion.

(Perhaps, instead of a patch, some tips could be added to the manual (or
to any other relevant site) so that users who want to extend this
functionality apply this type of hacks, as I have done in my particular
case...).

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: Org as a workspace (an impromptu reflection)
  2022-05-02 19:17  6% ` Nick Dokos
@ 2022-05-03 23:41 10%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-03 23:41 UTC (permalink / raw)
  To: Nick Dokos; +Cc: orgmode

Nick Dokos writes:

> From my vantage point (of ignorance about it :-) ), this sounds like
> org-roam to me: https://www.orgroam.com/

I've read here and there interesting things about org-roam, but I admit
I've never had the courage to try it. Partly due to lack of time and
partly because with my current Org setup I am reasonably satisfied. In
any case, everything I described I get with (if the expression is
allowed) 'org-vanilla' :-) (+ a number of must-have packages, such as
org-ql/helm-org-ql, org-super-links, org-transclusion, and more).

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [tip] Org speed commands improved
  2022-04-27  7:08  9%   ` Juan Manuel Macías
@ 2022-05-04 22:12  6%     ` TRS-80
  0 siblings, 0 replies; 200+ results
From: TRS-80 @ 2022-05-04 22:12 UTC (permalink / raw)
  To: emacs-orgmode

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

> Hi Ihor,
>
> Ihor Radchenko writes:
>
>> If you are going this far with speed commands, you might as well switch
>> to modal editing. What you are describing is basically a modal command
>> map with ability to switch to insert map.
>
> I'm not a fan of modal editing, rather the opposite. But in this
> particular case I have found that I spend very little time editing the
> raw content of the headers, once I set it. I spend more time editing the
> 'meta-content': TODO states, properties, tags, refile, attached folders,
> etc. And that with the speed commands can be achieved in a very agile
> way, so that a small dose of controlled modal editing and reduced only
> to the header, maybe it's worth it :-) If the speed commands were also
> activated in the content of the sections, here we would have a real
> modal editing, and that (in my case) would not be comfortable.

I agree with your assessment!  In fact, I think I will give your
functions a try.  Thanks for sharing them!

Cheers,
TRS-80



^ permalink raw reply	[relevance 6%]

* Re: Org and multimedia (tips?)
  2022-03-17 22:44  7% Org and multimedia (tips?) Juan Manuel Macías
  2022-03-18 14:40  6% ` Max Nikulin
@ 2022-05-05  1:14  5% ` TRS-80
  1 sibling, 0 replies; 200+ results
From: TRS-80 @ 2022-05-05  1:14 UTC (permalink / raw)
  To: emacs-orgmode

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

> Hi all,
>
> I've been trying for a while to use Org also to store and org-anize the
> data of my music and video files, so that I can conveniently access them
> via helm-org-ql and play them using EMMS.

I mean, I love Org just as much as anyone else on this list, but it does
not strike me as the right tool for this job?

In my mind anyway, I think first -- especially since you are storing
your files on an SBC on the network -- about some network based music
player like mpd or Mopidy (there are others, too).

There are many interfaces to those, including some in Emacs (maybe even
within EMMS, if I am recalling correctly).

But then you can also access your music from outside Emacs, too.  And
without needing to hack something up / re-invent the wheel in Org.

However, if you like to hack something up in Org instead, by all means,
continue!  :)

Cheers,
TRS-80



^ permalink raw reply	[relevance 5%]

* [PATCH] org-attach: Attach current Gnus article parts
@ 2022-05-07 14:31  8% Juan Manuel Macías
  2022-05-08 12:30  5% ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-07 14:31 UTC (permalink / raw)
  To: orgmode

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

Hi all,

In the attached patch I add a new command for org-attach: save *all*
attachments from the current Gnus article to the current org-attach-dir.

(Sorry for repeating the word "attach" so much :-))

NB:

1. If no Gnus article is open, it returns an error message.

2. I've only tested it on Emacs 28. I don't know if it can cause any
problems on earlier Emacs/Gnus versions.

3. Although there are several alternatives to Gnus, I have chosen Gnus
specifically because it is part of GNU Emacs.

4. I think an option could be added to save only certain types of files
(pdf, png, jpg, docx, etc.).

Best regards,

Juan Manuel


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-org-attach.el-new-command-to-attach-Gnus-curren.patch --]
[-- Type: text/x-patch, Size: 1865 bytes --]

From 03a53680df38300110c2095a98bc1dec8cc7adce Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 7 May 2022 16:04:06 +0200
Subject: [PATCH] lisp/org-attach.el: new command to attach Gnus current
 article parts

* (org-attach-gnus-save-parts-current-article): Attach current Gnus
article parts
* (org-attach-commands): add a new key
---
 lisp/org-attach.el | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 5ee2b84b2..54c8a2bdb 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -206,6 +206,8 @@ git-functionality from this file.")
      "Attach a file using symbolic-link method.")
     ((?u ?\C-u) org-attach-url
      "Attach a file from URL (downloading it).")
+    ((?g ?\C-g) org-attach-gnus-save-parts-current-article
+     "Attach current Gnus article parts")
     ((?b) org-attach-buffer
      "Select a buffer and attach its contents to the task.")
     ((?n ?\C-n) org-attach-new
@@ -488,6 +490,21 @@ DIR-property exists (that is different from the unset one)."
   (let ((org-attach-method 'url))
     (org-attach-attach url)))
 
+(defun org-attach-gnus-save-parts-current-article ()
+  "Attach current Gnus article parts."
+  (interactive)
+  (let* ((attach-dir (org-attach-dir 'get-create))
+	 (art gnus-article-current)
+	 (subject (gnus-summary-article-subject (cdr art))))
+    (if (not art)
+	(error "There is no open article")
+      (if (yes-or-no-p (format "Attach current article: \"%s\"" subject))
+	  (progn
+	    (org-attach-tag)
+	    (gnus-summary-save-parts "." attach-dir art)
+	    (message "New attachment: \"%s\"" subject))
+	(keyboard-quit)))))
+
 (defun org-attach-buffer (buffer-name)
   "Attach BUFFER-NAME's contents to current outline node.
 BUFFER-NAME is a string.  Signals a `file-already-exists' error
-- 
2.36.0


^ permalink raw reply related	[relevance 8%]

* Re: Export LaTeX command inside figure environment
  @ 2022-05-08  0:30 10% ` Juan Manuel Macías
  2022-05-08  0:57  7%   ` Thomas S. Dye
  2022-05-08  5:08  5%   ` Max Nikulin
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-08  0:30 UTC (permalink / raw)
  To: Thomas S. Dye; +Cc: orgmode

Hi, Thomas,

Thomas S. Dye writes:

> Is there a way to add an arbitrary LaTeX command between
> \begin{figure} ... \end{figure} during LaTeX export?  I want to end up
> with the following snippet, but can't figure out how to slip in
> \setfloatalignment{b}.  \begin{figure}[htb]
> \centering
> \includegraphics[width=.9\linewidth]{hilbertcurves.pdf}
> \caption[Hilbert curves]{\label{fig:orgparagraph1} Hilbert curves of
> various degrees \emph{n}.}
> \setfloatalignment{b}
> \end{figure}

I think the :caption attribute could do the trick (of course everything
must be on one line):

#+ATTR_LaTeX: :caption \caption[Hilbert
 curves]{\label{fig:orgparagraph1} Hilbert curves of various degrees
 \emph{n}.}\setfloatalignment{b}

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 10%]

* Re: Export LaTeX command inside figure environment
  2022-05-08  0:30 10% ` Juan Manuel Macías
@ 2022-05-08  0:57  7%   ` Thomas S. Dye
  2022-05-08  5:08  5%   ` Max Nikulin
  1 sibling, 0 replies; 200+ results
From: Thomas S. Dye @ 2022-05-08  0:57 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Thomas S. Dye, orgmode

Aloha Juan Manuel,

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

> Hi, Thomas,
>
> Thomas S. Dye writes:
>
>> Is there a way to add an arbitrary LaTeX command between
>> \begin{figure} ... \end{figure} during LaTeX export?  I want to 
>> end up
>> with the following snippet, but can't figure out how to slip in
>> \setfloatalignment{b}.  \begin{figure}[htb]
>> \centering
>> \includegraphics[width=.9\linewidth]{hilbertcurves.pdf}
>> \caption[Hilbert curves]{\label{fig:orgparagraph1} Hilbert 
>> curves of
>> various degrees \emph{n}.}
>> \setfloatalignment{b}
>> \end{figure}
>
> I think the :caption attribute could do the trick (of course 
> everything
> must be on one line):
>
> #+ATTR_LaTeX: :caption \caption[Hilbert
>  curves]{\label{fig:orgparagraph1} Hilbert curves of various 
>  degrees
>  \emph{n}.}\setfloatalignment{b}
>

That works.  Thanks!

All the best,
Tom

-- 
Thomas S. Dye
https://tsdye.online/tsdye


^ permalink raw reply	[relevance 7%]

* Re: Export LaTeX command inside figure environment
  2022-05-08  0:30 10% ` Juan Manuel Macías
  2022-05-08  0:57  7%   ` Thomas S. Dye
@ 2022-05-08  5:08  5%   ` Max Nikulin
  2022-05-08  6:06  0%     ` Thomas S. Dye
  1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2022-05-08  5:08 UTC (permalink / raw)
  To: emacs-orgmode

On 08/05/2022 07:30, Juan Manuel Macías wrote:
> Thomas S. Dye writes:
> 
>> Is there a way to add an arbitrary LaTeX command between
>> \begin{figure} ... \end{figure} during LaTeX export?  I want to end up
>> with the following snippet, but can't figure out how to slip in
>> \setfloatalignment{b}.  \begin{figure}[htb]
>> \centering
>> \includegraphics[width=.9\linewidth]{hilbertcurves.pdf}
>> \caption[Hilbert curves]{\label{fig:orgparagraph1} Hilbert curves of
>> various degrees \emph{n}.}
>> \setfloatalignment{b}
>> \end{figure}
> 
> I think the :caption attribute could do the trick (of course everything
> must be on one line):
> 
> #+ATTR_LaTeX: :caption \caption[Hilbert
>   curves]{\label{fig:orgparagraph1} Hilbert curves of various degrees
>   \emph{n}.}\setfloatalignment{b}

Would it work if \setfloatalignment{b} is added before \includegraphics? 
 From my point of view, it is still a hack due to abusing the :placement 
attribute, but it is backend agnostic, so reuses caption for HTML and 
relieves requirement of single long line:

#+caption[Hilbert curves]: Hilbert curves of various degrees \(n\)
#+name: orgparagraph1
#+attr_latex: :placement [b]\setfloatalignment{b}
[[file:hilbertcurves.pdf]]

# Local Variables:
# org-latex-prefer-user-labels: t
# End:

P.S. Math and absence of period are intentional. I never used tufte, so 
unsure if something besides b is meaningful with \setfloatalignment{b}. 
I dropped "ht" to make inconsistency apparent and expecting that when 
figures are moved to the end of document, "ht" should be used instead 
with removing of \setfloatalignment.



^ permalink raw reply	[relevance 5%]

* Re: Export LaTeX command inside figure environment
  2022-05-08  5:08  5%   ` Max Nikulin
@ 2022-05-08  6:06  0%     ` Thomas S. Dye
  2022-05-08 16:12  8%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Thomas S. Dye @ 2022-05-08  6:06 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> On 08/05/2022 07:30, Juan Manuel Macías wrote:
>> Thomas S. Dye writes:
>> 
>>> Is there a way to add an arbitrary LaTeX command between
>>> \begin{figure} ... \end{figure} during LaTeX export?  I want 
>>> to end up
>>> with the following snippet, but can't figure out how to slip 
>>> in
>>> \setfloatalignment{b}.  \begin{figure}[htb]
>>> \centering
>>> \includegraphics[width=.9\linewidth]{hilbertcurves.pdf}
>>> \caption[Hilbert curves]{\label{fig:orgparagraph1} Hilbert 
>>> curves of
>>> various degrees \emph{n}.}
>>> \setfloatalignment{b}
>>> \end{figure}
>> I think the :caption attribute could do the trick (of course 
>> everything
>> must be on one line):
>> #+ATTR_LaTeX: :caption \caption[Hilbert
>>   curves]{\label{fig:orgparagraph1} Hilbert curves of various 
>>   degrees
>>   \emph{n}.}\setfloatalignment{b}
>
> Would it work if \setfloatalignment{b} is added before 
> \includegraphics?  From
> my point of view, it is still a hack due to abusing the 
> :placement attribute,
> but it is backend agnostic, so reuses caption for HTML and 
> relieves requirement
> of single long line:
>
> #+caption[Hilbert curves]: Hilbert curves of various degrees 
> \(n\)
> #+name: orgparagraph1
> #+attr_latex: :placement [b]\setfloatalignment{b}
> [[file:hilbertcurves.pdf]]
>
> # Local Variables:
> # org-latex-prefer-user-labels: t
> # End:
>
> P.S. Math and absence of period are intentional. I never used 
> tufte, so unsure
> if something besides b is meaningful with \setfloatalignment{b}. 
> I dropped "ht"
> to make inconsistency apparent and expecting that when figures 
> are moved to the
> end of document, "ht" should be used instead with removing of
> \setfloatalignment.

Yes, this works, too.  It is a convenient hack. Thanks!

It would be better to have a LaTeX attribute, say :commands, that 
places commands within \begin{figure} ... \end{figure}.

I'm circling back to Tufte handouts for a course I'm offering in 
the Fall.  It is great that ox-latex has the flexibility to export 
to tufte-latex now.  I haven't prepared any handouts yet, but all 
the pieces seem to work in a straightforward way.  Org-cite is 
performing like a champ, too!

All the best,
Tom
-- 
Thomas S. Dye
https://tsdye.online/tsdye


^ permalink raw reply	[relevance 0%]

* Re: [PATCH] org-attach: Attach current Gnus article parts
  2022-05-07 14:31  8% [PATCH] org-attach: Attach current Gnus article parts Juan Manuel Macías
@ 2022-05-08 12:30  5% ` Ihor Radchenko
  2022-05-08 13:23  9%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-08 12:30 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> In the attached patch I add a new command for org-attach: save *all*
> attachments from the current Gnus article to the current org-attach-dir.
>
> (Sorry for repeating the word "attach" so much :-))
>
> NB:
>
> 1. If no Gnus article is open, it returns an error message.
>
> 2. I've only tested it on Emacs 28. I don't know if it can cause any
> problems on earlier Emacs/Gnus versions.
>
> 3. Although there are several alternatives to Gnus, I have chosen Gnus
> specifically because it is part of GNU Emacs.
>
> 4. I think an option could be added to save only certain types of files
> (pdf, png, jpg, docx, etc.).

I think that supporting only Gnus is too specific. Not all the people
use Gnus as mail reader. And the extra menu option you propose will only
eat up space for people not using Gnus.

I'd prefer a more generic approach working in any kind of email reader,
be it rmail, gnus, mu4e, notmuch, or wunderlust. The approach can
probably making use of message-mode or MML libraries from Emacs core.

Also, I do not like adding yet another menu option even if it is working
for other mail readers. Instead, it would be more consistent to follow
what we do for dired. See interactive spec in org-attach-attach.

Best,
Ihor


^ permalink raw reply	[relevance 5%]

* Re: [PATCH] org-attach: Attach current Gnus article parts
  2022-05-08 12:30  5% ` Ihor Radchenko
@ 2022-05-08 13:23  9%   ` Juan Manuel Macías
  2022-05-08 14:18  5%     ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-08 13:23 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> I think that supporting only Gnus is too specific. Not all the people
> use Gnus as mail reader. And the extra menu option you propose will only
> eat up space for people not using Gnus.
>
> I'd prefer a more generic approach working in any kind of email reader,
> be it rmail, gnus, mu4e, notmuch, or wunderlust. The approach can
> probably making use of message-mode or MML libraries from Emacs core.

Well, as I said, I have chosen Gnus because it is part of GNU Emacs. In
any case, if anyone wants to write a patch with a more general solution,
I'd encourage them. I think that would be an interesting feature for
org-attach. I only use Gnus and unfortunately I'm not familiar with
other mail reader libraries (I could try to do something more "agnostic"
from message-mode, when I have some more time...).

What I don't quite understand is why it wouldn't be appropriate to add a
new entry with the new feature to the org-attach menu.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: [PATCH] org-attach: Attach current Gnus article parts
  2022-05-08 13:23  9%   ` Juan Manuel Macías
@ 2022-05-08 14:18  5%     ` Ihor Radchenko
  2022-05-08 18:06 10%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-08 14:18 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> What I don't quite understand is why it wouldn't be appropriate to add a
> new entry with the new feature to the org-attach menu.

Thinking about it more, new feature in org-attach menu should actually
be ok.

My initial logic was that we cannot easily select attach method for
entries in the attach menu. However, anything other than 'cp method is
meaningless when saving article attachments.

> Well, as I said, I have chosen Gnus because it is part of GNU Emacs. In
> any case, if anyone wants to write a patch with a more general solution,
> I'd encourage them. I think that would be an interesting feature for
> org-attach. I only use Gnus and unfortunately I'm not familiar with
> other mail reader libraries (I could try to do something more "agnostic"
> from message-mode, when I have some more time...).

I think that a good example implementation is from notmuch.el. It does
not use anything specific to notmuch, just built-in mm-*.el from gnus:

(defun notmuch-save-attachments (mm-handle &optional queryp)
  (notmuch-foreach-mime-part
   (lambda (p)
     (let ((disposition (mm-handle-disposition p)))
       (and (listp disposition)
	    (or (equal (car disposition) "attachment")
		(and (equal (car disposition) "inline")
		     (assq 'filename disposition)))
	    (or (not queryp)
		(y-or-n-p
		 (concat "Save '" (cdr (assq 'filename disposition)) "' ")))
	    (mm-save-part p))))
   mm-handle))

(defun notmuch-foreach-mime-part (function mm-handle)
  (cond ((stringp (car mm-handle))
	 (dolist (part (cdr mm-handle))
	   (notmuch-foreach-mime-part function part)))
	((bufferp (car mm-handle))
	 (funcall function mm-handle))
	(t (dolist (part mm-handle)
	     (notmuch-foreach-mime-part function part)))))

Best,
Ihor


^ permalink raw reply	[relevance 5%]

* Re: Export LaTeX command inside figure environment
  2022-05-08  6:06  0%     ` Thomas S. Dye
@ 2022-05-08 16:12  8%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-08 16:12 UTC (permalink / raw)
  To: Thomas S. Dye; +Cc: Maxim Nikulin, orgmode

Thomas S. Dye writes:

> It would be better to have a LaTeX attribute, say :commands, that
> places commands within \begin{figure} ... \end{figure}.

This is a possible solution from the LaTeX side, which would avoid
having to modify the Org code and can also be used to introduce more
complex arbitrary code into the figure environment. It consists of
defining a variable (for arbitrary code) and redefining the figure
environment to include that variable. Something like this:

#+NAME: preamble
#+begin_src latex :exports none
\usepackage{graphicx,xparse}

\def\myfigcode#1{#1}

\let\svfigure\figure
\let\endsvfigure\endfigure

\DeclareDocumentEnvironment{figure}{o}{%
\IfNoValueTF{#1}{%
  \begin{svfigure}}
  {\begin{svfigure}[#1]}
    \myfigcode%
}
{\end{svfigure}}
#+end_src

#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <<preamble>>
#+end_src

Here I use the dummy images from the graphicx package. Of course, then
it is necessary to apply a zero value to the variable again, or enclose
all in a \begingroup...\endgroup. It's a bit tricky and I haven't tried
it too much:

@@latex:\begingroup\def\myfigcode{{\centering\fbox{\textbf{Hello world!!!}}\par\vspace{5ex}}}@@

#+caption: This is a caption
#+ATTR_LaTeX: :placement [h] :width .5\linewidth
[[file:example-image-a.jpg]]

@@latex:\endgroup@@

#+caption: This is a caption
#+ATTR_LaTeX: :placement [h] :width .5\linewidth
[[file:example-image-b.jpg]]

A screenshot:

https://i.imgur.com/8JIU6nX.png

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: [PATCH] org-attach: Attach current Gnus article parts
  2022-05-08 14:18  5%     ` Ihor Radchenko
@ 2022-05-08 18:06 10%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-08 18:06 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> I think that a good example implementation is from notmuch.el. It does
> not use anything specific to notmuch, just built-in mm-*.el from gnus:

Thanks for the tip, Ihor. I'll take a look at it, and see if I can
sketch something usable...

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* [tip] Insert arbitrary LaTeX code at the beginning of any float environment
@ 2022-05-08 22:22  7% Juan Manuel Macías
  2022-05-09 12:47  6% ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-08 22:22 UTC (permalink / raw)
  To: orgmode

Hi all,

If we want to introduce arbitrary LaTeX code at the very beginning of a
float environment, apart from the usual tricks of putting the code in
:caption or :placement, this solution I describe here is more from the
LaTeX side. I thik its advantages are more control and consistency from
the point of view of LaTeX, and the possibility of introducing code of a
certain complexity.

Well, you have to write some LaTeX code for the preamble, but it's
really not much :)

We have to define a global command \myenvcode{<arbitrary code>} (if we
want to add the code to all document floats environments), and also a
'Myenvcode' environment, with the same argument. The etoolbox LaTeX
package provides a number of hooks: \AtBeginEnvironment,
\AtEndEnvironment, etc., but if we want our arbitrary code to be at the
very beginning of the environment, it's safer to use the \@floatboxreset
hook. So, the code that we would have to add to our preamble would be (I
prefer to define the command and environment using the xparse syntax):

#+NAME: preamble
#+begin_src latex :exports none
  \usepackage{xparse}

  \makeatletter
  \def\my@envcode{}
  \NewDocumentCommand{\myenvcode}{+m}{%
    \def\my@envcode{#1}}
  \g@addto@macro\@floatboxreset{\my@envcode}
  \makeatother

  \NewDocumentEnvironment{Myenvcode}{+m}{%
    \IfNoValueF{#1}{\myenvcode{#1}}}
  {\par}
#+end_src

#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <<preamble>>
#+end_src

And here a few examples:

#+ATTR_LaTeX: :options {\centering\fbox{Code before a image}\par\vspace{1ex}}
#+begin_Myenvcode
#+CAPTION: This is a image
#+ATTR_LaTeX: :width .5\linewidth :placement [h]
[[file:example-image-a.jpg]]
#+end_Myenvcode

#+ATTR_LaTeX: :options {\captionsetup{font={color=red}}}
#+begin_Myenvcode
#+CAPTION: This is a image
#+ATTR_LaTeX: :width .5\linewidth :placement [h]
[[file:example-image-b.jpg]]
#+end_Myenvcode

#+latex: \myenvcode{{\centering\fbox{Code before a table}\par\vspace{1ex}}}
#+CAPTION: This is a table
#+ATTR_LaTeX: :placement [h] :booktabs t
| a | b | c | d | f |
|---+---+---+---+---|
| 1 | 2 | 3 | 4 | 5 |

#+latex: \myenvcode{}

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 7%]

* Re: [tip] Insert arbitrary LaTeX code at the beginning of any float environment
  2022-05-08 22:22  7% [tip] Insert arbitrary LaTeX code at the beginning of any float environment Juan Manuel Macías
@ 2022-05-09 12:47  6% ` Ihor Radchenko
  2022-05-09 14:01 10%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-09 12:47 UTC (permalink / raw)
  To: Juan Manuel Macías, Timothy; +Cc: orgmode

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

> If we want to introduce arbitrary LaTeX code at the very beginning of a
> float environment, apart from the usual tricks of putting the code in
> :caption or :placement, this solution I describe here is more from the
> LaTeX side. I thik its advantages are more control and consistency from
> the point of view of LaTeX, and the possibility of introducing code of a
> certain complexity.

I'd be happy to see a built-in solution for this.
I feel that the ability to insert arbitrary LaTeX code near the
begin/end of environment would be generally a useful feature to have in
ox-latex. It could be done via #+attr_latex: :pre/:post

Moreover, it would be useful to be able to wrap the whole chunk into
custom environment:
#+attr_latex: :wrap [options]environmant

WDYT?

Best,
Ihor


^ permalink raw reply	[relevance 6%]

* Re: [tip] Insert arbitrary LaTeX code at the beginning of any float environment
  2022-05-09 12:47  6% ` Ihor Radchenko
@ 2022-05-09 14:01 10%   ` Juan Manuel Macías
  2022-05-09 14:14  6%     ` Eric S Fraga
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-09 14:01 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Eric S Fraga, orgmode

Ihor Radchenko writes:

> I'd be happy to see a built-in solution for this.
> I feel that the ability to insert arbitrary LaTeX code near the
> begin/end of environment would be generally a useful feature to have in
> ox-latex. It could be done via #+attr_latex: :pre/:post
>
> Moreover, it would be useful to be able to wrap the whole chunk into
> custom environment:
> #+attr_latex: :wrap [options]environmant
>
> WDYT?

I think they are both great ideas, especially the second one. Although
---as Eric says--- we can always use special blocks, a :wrap attribute
would drastically lighten the readability of the document, and could be
very useful in those complex constructions where we need to enclose a
table or a figure in another environment (for example, with the
threeparttable package and others like it).

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [tip] Insert arbitrary LaTeX code at the beginning of any float environment
  2022-05-09 14:01 10%   ` Juan Manuel Macías
@ 2022-05-09 14:14  6%     ` Eric S Fraga
  0 siblings, 0 replies; 200+ results
From: Eric S Fraga @ 2022-05-09 14:14 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Ihor Radchenko, orgmode

On Monday,  9 May 2022 at 14:01, Juan Manuel Macías wrote:
> Although ---as Eric says--- we can always use special blocks, a :wrap
> attribute would drastically lighten the readability of the document,

One advantage of special blocks is that they work across all
(some/most/?) export backends and are not tied to LaTeX.

-- 
: Eric S Fraga, with org release_9.5.3-478-g2a6f5c in Emacs 29.0.50


^ permalink raw reply	[relevance 6%]

* A function that converts a LaTeX document to an Elisp expression (for org-latex-classes)
@ 2022-05-10 10:32  7% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-10 10:32 UTC (permalink / raw)
  To: orgmode

Hi all,

In case anyone finds it useful, I'm sharing this function here that I
recently wrote, to convert a LaTeX buffer to an Elisp expression,
suitable for adding to `org-latex-classes'. It's a bit rudimentary, but
I think it does the trick. It can be useful for long preambles with a
lot of (La)TeX code. Although if you are dealing with bizarrely large preambles
that are used often, I would recommend writing your own .sty file
(https://tex.stackexchange.com/questions/8750/make-your-own-sty-files).
The funny thing is that doing it from Org is much easier than from the
official LaTeX utility for creating packages through literary
programming, docstrip.

As for my function, the LaTeX document to be converted must have this skeleton:

- Preamble

- `\begin{document}'

- An ordered list of section names (one name per line). For example:

  chapter
  section
  subsection
  susbsubsection
  etc

- `\end{document}'

Best regards,

Juan Manuel

#+begin_src emacs-lisp
  (defun create-new-org-latex-class-from-latex-buffer ()
    "Convert the current LaTeX buffer to an appropriate Elisp
  expression to add to `org-latex-classes'. The LaTeX document must
  have the following structure:
   - Preamble
   - `\begin{document}'
   - A list of section names (one name per line). For example:
     section
     subsection
     susbsubsection
     etc
  - `\end{document}'"
    (interactive)
    (if (not (equal (format "%s" major-mode) "latex-mode"))
	(error "Not in a LaTeX buffer")
      (let* ((class-name (read-from-minibuffer "Class name: "))
	     (preamble-beg (with-current-buffer
			       (buffer-name)
			     (save-excursion
			       (goto-char (point-min))
			       (point))))
	     (preamble-end (with-current-buffer
			       (buffer-name)
			     (save-excursion
			       (goto-char (point-min))
			       (re-search-forward "\\\\begin{document}" nil t)
			       (beginning-of-line)
			       (point))))
	     (packages "[NO-DEFAULT-PACKAGES]
		       [PACKAGES]
		       [EXTRA]")
	     (preamble (concat
			(buffer-substring-no-properties preamble-beg preamble-end)
			packages))
	     (preamble-list (list preamble))
	     (sections-list)
	     (sections-list-populate (with-current-buffer (buffer-name)
				       (save-excursion
					 (goto-char (point-min))
					 (let ((beg-sec
						(save-excursion
						  (re-search-forward "\\\\begin{document}" nil t)
						  (point)))
					       (end-sec
						(save-excursion
						  (re-search-forward "\\\\end{document}" nil t)
						  (beginning-of-line)
						  (point))))
					   (save-restriction
					     (narrow-to-region beg-sec end-sec)
					     (while (re-search-forward "\\(^.+\\)" nil t)
					       (push (substring-no-properties (match-string 1)) sections-list)))
					   (reverse sections-list)))))
	     (section-list-final (mapcar
				  (lambda (x)
				    (let ((car (format "\\%s{%%s}" x))
					  (cdr (format "\\%s*{%%s}" x)))
				      (cons car cdr)))
				  sections-list-populate))
	     (list-final (append (list class-name) preamble-list section-list-final))
	     (format-list (format "%S" list-final)))
	(when (get-buffer "*class*")
	  (kill-buffer "*class*"))
	(get-buffer-create "*class*")
	(with-current-buffer "*class*"
	  (insert format-list))
	(temp-buffer-window-show "*class*"))))
#+end_src


^ permalink raw reply	[relevance 7%]

* Re: export to latex: begin_example gets exported to verbatim (
  @ 2022-05-12  8:52 10%     ` Juan Manuel Macías
  2022-05-12 10:02  0%       ` Uwe Brauer
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-12  8:52 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode

Hi Uwe,

Uwe Brauer writes:

> Which gets exported to verbatim not lstlisting as I want

Try adding this:

:wrap lstlisting

(I don't use matlab, but I think that should work).

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: export to latex: begin_example gets exported to verbatim (
  2022-05-12  8:52 10%     ` Juan Manuel Macías
@ 2022-05-12 10:02  0%       ` Uwe Brauer
  0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2022-05-12 10:02 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode

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

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

> Hi Uwe,
> Uwe Brauer writes:

>> Which gets exported to verbatim not lstlisting as I want

> Try adding this:

> :wrap lstlisting

It does! Thanks!

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

^ permalink raw reply	[relevance 0%]

* citation-style-language: new LaTeX package in TL 2022
@ 2022-05-12 10:44  9% Juan Manuel Macías
  2022-05-12 11:34  6% ` Bruce D'Arcus
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-12 10:44 UTC (permalink / raw)
  To: orgmode

Hi all,

TeX Live 2022 includes a new LaTeX package for citations,
'citation-style-language', written by Zeping Lee. According to the
package description:

"[...] The citation-style-language package is aimed to provide another
reference formatting method for LaTeX that utilizes the CSL styles. It
contains a citation processor implemented in pure Lua (citeproc-lua)
which reads bibliographic metadata and performs sorting and formatting
on both citations and bibliography according to the selected CSL style.
A LaTeX package (citation-style-language.sty) is provided to communicate
with the processor."

https://ctan.org/pkg/citation-style-language

https://github.com/zepinglee/citeproc-lua

I'm not sufficiently familiar (at the moment) with org-cite, but I share
the news here in case this new LaTeX package could have some kind of use
for org-cite export options.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: citation-style-language: new LaTeX package in TL 2022
  2022-05-12 10:44  9% citation-style-language: new LaTeX package in TL 2022 Juan Manuel Macías
@ 2022-05-12 11:34  6% ` Bruce D'Arcus
  0 siblings, 0 replies; 200+ results
From: Bruce D'Arcus @ 2022-05-12 11:34 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On Thu, May 12, 2022 at 7:11 AM Juan Manuel Macías
<maciaschain@posteo.net> wrote:

> I'm not sufficiently familiar (at the moment) with org-cite, but I share
> the news here in case this new LaTeX package could have some kind of use
> for org-cite export options.

I've played with it a bit, and it does look promising.

I think whether and where it might fit in org-cite (a feature added to
oc-csl, or a new export processor) might depend on how its command
options evolve. Right now, it has a single "cite" command.

Bruce


^ permalink raw reply	[relevance 6%]

* Re: simple request letter - help
  @ 2022-05-13 17:04 10% ` Juan Manuel Macías
  2022-05-13 17:19  2%   ` andrés ramírez
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-13 17:04 UTC (permalink / raw)
  To: Andrés Ramírez; +Cc: orgmode

Hi Andrés,

Andrés Ramírez writes:

> When I export the file M-x org-export-distpach l p
>
> The second and third paragraph do nat have right alignment as the first
> paragraph.

Can you please copy the contents of your .tex file here: `M-x
org-export-disptatch l l'?

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: simple request letter - help
  2022-05-13 17:04 10% ` Juan Manuel Macías
@ 2022-05-13 17:19  2%   ` andrés ramírez
  2022-05-13 18:22  8%     ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: andrés ramírez @ 2022-05-13 17:19 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

    Juan> Can you please copy the contents of your .tex file here: `M-x org-export-disptatch l l'?

--8<---------------cut here---------------start------------->8---
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\date{}
\title{}
\hypersetup{
 pdfauthor={Andrés Ramírez},
 pdftitle={},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 28.1 (Org mode 9.5.2)}, 
 pdflang={English}}
\begin{document}


\section*{}
\label{sec:orgbc8783b}
Me John Doe with ID number XXXXXXXX request to install me the water service \ldots{}.

\bigskip
I am sharing the payment receipt for the service in an attachment

\bigskip
Sincerely.

\makebox[1.5in]{\hrulefill} \hspace {1.0in} \\
& John Doe \\
& ID: XXXXXXXX\\
\end{document}
--8<---------------cut here---------------end--------------->8---


Best Regards


^ permalink raw reply	[relevance 2%]

* Re: simple request letter - help
  2022-05-13 17:19  2%   ` andrés ramírez
@ 2022-05-13 18:22  8%     ` Juan Manuel Macías
  2022-05-13 19:06  3%       ` andrés ramírez
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-13 18:22 UTC (permalink / raw)
  To: andrés ramírez; +Cc: orgmode

hi Andrés,

andrés ramírez writes:

> Hi. Juan.
> My comments below.

I'll explain what happens. There really isn't an alignment issue. TeX by
default applies a first line indent to paragraphs. It also defaults to
applying English typographical conventions, as is the case in your
document, where the first paragraph following a section is not indented.
This is what is happening :):

section
no indent -------------
indent       ----------
indent       ----------

Another more general typographical convention is that when paragraphs
are separated by a vertical space, they do not need to indent the first
line, as it is a redundant mark. Besides, you are making paragraph
separation by direct format (\bigskip). I usually recommend not applying
direct format in LaTeX, or applying it as little as possible. To disable
the first line indentation and make the paragraphs have a space between
them, it is enough that you add this:

#+LaTeX_Header: \parindent=0em\parskip=\bigskipamount

That way, you're giving the first line indentation a global value of
zero and a paragraph spacing value equivalent to \bigskip, and you don't
need to put a \bigsip every time you start a paragraph.

On the other hand, this code at the end does not give you an error?

\makebox[1.5in]{\hrulefill} \hspace {1.0in} \\
& John Doe \\
& ID: XXXXXXXX\\

best regards, 

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: simple request letter - help
  2022-05-13 18:22  8%     ` Juan Manuel Macías
@ 2022-05-13 19:06  3%       ` andrés ramírez
  2022-05-13 20:30  9%         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: andrés ramírez @ 2022-05-13 19:06 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Hi. Juan.
My comments below.

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

[...]

    Juan> section is not indented.  This is what is happening :):

That is good to know.

    Juan> section no indent ------------- indent ---------- indent ----------

[...]

    Juan> is enough that you add this:

    Juan> #+LaTeX_Header: \parindent=0em\parskip=\bigskipamount

It worked for most part of the document. But I Think I need the double
of space before the signature.

[...]

    Juan> On the other hand, this code at the end does not give you an error?

    Juan> \makebox[1.5in]{\hrulefill} \hspace {1.0in} \\ & John Doe \\ & ID: XXXXXXXX\\

Right. It is giving me an error I have NOT noticed it because the pdf is
being generated.

Best Regards


^ permalink raw reply	[relevance 3%]

* Re: simple request letter - help
  2022-05-13 19:06  3%       ` andrés ramírez
@ 2022-05-13 20:30  9%         ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-13 20:30 UTC (permalink / raw)
  To: andrés ramírez; +Cc: orgmode

andrés ramírez writes:

> Right. It is giving me an error I have NOT noticed it because the pdf is
> being generated.

Your document is probably compiled on export with the
`-intercaction=nonstopmode' option, and thus does not break the
compilation with an error. In any case, I don't really understand why
you export that part literally to LaTeX and why you add the & at
beginning of line:

& John Doe\\
& ID: XXXXXXXX

Those characters are usually reserved for tabular
environments, so LaTeX returns an error. If you want to use an &
literally in LaTeX you must escape it as \&. But if you write the
anpersand directly in Org Mode you don't need to escape it, since Org
takes care of it when it exports the document.

Also, in the signature you could also avoid direct formatting. You can
define a simple environment, with an extra space before it, if you need
to add that space. This is a very elementary example, based on your
format. Then you can use in Org a special block, with the name of the
environment:

#+LaTeX_Header: \newenvironment{signature}{\bigskip\raggedright\makebox[1.5in]{\hrulefill}\par}{\par}

#+begin_signature
John Doe

ID: XXXXXXXX
#+end_signature

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: I can't set dabbrev to respect the writen case
  @ 2022-05-14 22:32 10% ` Juan Manuel Macías
  2022-05-15 10:40  7%   ` Ypo
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-14 22:32 UTC (permalink / raw)
  To: Ypo; +Cc: orgmode

Ypo writes:

> Hi
>
> I find dabbrev and fancy-dabbrev very useful to typing fast. But there
> is a problem I am not able to solve: When I apply an expansion while
> writing, the case is always that of the expansion, I can't make it to
> respect what I have written. An example:
>
> — (Typing) "Hel
>
> — (Offered expansion) "hello"
>
> — (What I get when accepting the expansion) "hello"
>
> — (What I wanted) "Hello"
>
> Best regards,
>
> Ypo
>

Take a look at these variables. I have them configured as non-nil:

(setq dabbrev-case-replace t)

(setq dabbrev-case-fold-search t)

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: I can't set dabbrev to respect the writen case
  2022-05-14 22:32 10% ` Juan Manuel Macías
@ 2022-05-15 10:40  7%   ` Ypo
  2022-05-15 13:58 10%     ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ypo @ 2022-05-15 10:40 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

Thanks, Juan Manuel.

These are my variables, it keeps changing what I have already written:

'(case-replace nil)

  '(dabbrev-case-distinction t)
  '(dabbrev-case-fold-search t)
  '(dabbrev-case-replace t)
  '(dabbrev-upcase-means-case-search nil)

Best regards,

Ypo

El 15/05/2022 a las 0:32, Juan Manuel Macías escribió:
> Ypo writes:
>
>> Hi
>>
>> I find dabbrev and fancy-dabbrev very useful to typing fast. But there
>> is a problem I am not able to solve: When I apply an expansion while
>> writing, the case is always that of the expansion, I can't make it to
>> respect what I have written. An example:
>>
>> — (Typing) "Hel
>>
>> — (Offered expansion) "hello"
>>
>> — (What I get when accepting the expansion) "hello"
>>
>> — (What I wanted) "Hello"
>>
>> Best regards,
>>
>> Ypo
>>
> Take a look at these variables. I have them configured as non-nil:
>
> (setq dabbrev-case-replace t)
>
> (setq dabbrev-case-fold-search t)
>
> Best regards,
>
> Juan Manuel

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

^ permalink raw reply	[relevance 7%]

* [tip] Export and open a PDF in Android via Termux
@ 2022-05-15 11:54  9% Juan Manuel Macías
  2022-05-16 12:35  6% ` Ihor Radchenko
  2022-05-16 15:00  6% ` Max Nikulin
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-15 11:54 UTC (permalink / raw)
  To: orgmode

Hi all,

I have recently installed TeX live on Android inside Termux:

$ pkg install texlive-installer

(https://wiki.termux.com/wiki/TeX_Live)

And I've managed to open a PDF exported from Org using an external
android viewer (mupdf, downloaded from f-droid). The Termux command is
termux-open. You need to add:

(setq org-file-apps
      '((auto-mode . emacs)
 (directory . emacs)
 ("\\.mm\\'" . default)
 ("\\.x?html?\\'" . default)
 ("\\.pdf\\'" . "termux-open %s")))

It is necessary also to uncomment the line 'allow-external-apps = true' in '~/.termux/termux.properties'.

And to open the PDF from AUCTeX:

(setq TeX-view-program-list '(("termux" "termux-open %o")))

(setq TeX-view-program-selection
'(((output-dvi has-no-display-manager)
  "dvi2tty")
 ((output-dvi style-pstricks)
  "dvips and gv")
 (output-dvi "xdvi")
 (output-pdf "termux")
 (output-html "xdg-open")))

A screencast: https://imgur.com/a/iBvwDTo

Best regards,

Juan Manuel 



^ permalink raw reply	[relevance 9%]

* Re: I can't set dabbrev to respect the writen case
  2022-05-15 10:40  7%   ` Ypo
@ 2022-05-15 13:58 10%     ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-15 13:58 UTC (permalink / raw)
  To: Ypo; +Cc: orgmode

Ypo writes:

> These are my variables, it keeps changing what I have already written:
>
> '(case-replace nil)
>
>  '(dabbrev-case-distinction t)
>  '(dabbrev-case-fold-search t)
>  '(dabbrev-case-replace t)
>  '(dabbrev-upcase-means-case-search nil)

With those values it works for me as expected. Maybe it's a problem with
your configuration. Try starting emacs with 'emacs -q' and evaluate the
variables with:

M-x eval-expression 

(setq dabbrev-case-distinction t       
      dabbrev-case-fold-search t
      dabbrev-case-replace t           
      abbrev-upcase-means-case-search nil)

RET

I hardly use dabbrev and I'm afraid I can't give you any more tips.
Try asking <emacs-devel@gnu.org> as well.

Best regards,

Juan Manuel 






^ permalink raw reply	[relevance 10%]

* Re: [tip] Export and open a PDF in Android via Termux
  2022-05-15 11:54  9% [tip] Export and open a PDF in Android via Termux Juan Manuel Macías
@ 2022-05-16 12:35  6% ` Ihor Radchenko
  2022-05-16 15:00  6% ` Max Nikulin
  1 sibling, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-05-16 12:35 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> I have recently installed TeX live on Android inside Termux:
>
> $ pkg install texlive-installer
>
> (https://wiki.termux.com/wiki/TeX_Live)
>
> And I've managed to open a PDF exported from Org using an external
> android viewer (mupdf, downloaded from f-droid). The Termux command is
> termux-open. You need to add:
>
> (setq org-file-apps
>       '((auto-mode . emacs)
>  (directory . emacs)
>  ("\\.mm\\'" . default)
>  ("\\.x?html?\\'" . default)
>  ("\\.pdf\\'" . "termux-open %s")))

Thanks for sharing! I am wondering if tips like this should be added to
worg.

Best,
Ihor


^ permalink raw reply	[relevance 6%]

* Re: [tip] Export and open a PDF in Android via Termux
  2022-05-15 11:54  9% [tip] Export and open a PDF in Android via Termux Juan Manuel Macías
  2022-05-16 12:35  6% ` Ihor Radchenko
@ 2022-05-16 15:00  6% ` Max Nikulin
  2022-05-16 16:05 10%   ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2022-05-16 15:00 UTC (permalink / raw)
  To: emacs-orgmode

On 15/05/2022 18:54, Juan Manuel Macías wrote:
> 
> (setq org-file-apps
>        '((auto-mode . emacs)
>   (directory . emacs)
>   ("\\.mm\\'" . default)
>   ("\\.x?html?\\'" . default)
>   ("\\.pdf\\'" . "termux-open %s")))

Does termux have a notion of mailcap, e.g. mime-support package or 
something similar? I have a hope that

     application/pdf; termux-open %s

in /etc/mailcap or in ~/.mailcap might be enough instead of explicit 
configuration of particular packages.



^ permalink raw reply	[relevance 6%]

* Re: [tip] Export and open a PDF in Android via Termux
  2022-05-16 15:00  6% ` Max Nikulin
@ 2022-05-16 16:05 10%   ` Juan Manuel Macías
  2022-05-17 16:22  5%     ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-16 16:05 UTC (permalink / raw)
  To: Max Nikulin; +Cc: Ihor Radchenko, Eric S. Fraga, orgmode

Max Nikulin writes:

> Does termux have a notion of mailcap, e.g. mime-support package or
> something similar? I have a hope that
>
>     application/pdf; termux-open %s
>
> in /etc/mailcap or in ~/.mailcap might be enough instead of explicit
> configuration of particular packages.

I've been playing with Termux for a short time and what you're
suggesting hadn't occurred to me. Indeed, it works fine with a
~/.mailcap file! I have done a test with an attachment in Gnus:

https://imgur.com/a/g1Auvxp

Termux is quite interesting (and addictive :-)). Now I am playing with
Termux-api to send notifications from Emacs/Gnus to Android (with
gnus-desktop-notifier and the termux-notification command). And also to
send sms from Emacs and bbdb...

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [tip] Export and open a PDF in Android via Termux
  2022-05-16 16:05 10%   ` Juan Manuel Macías
@ 2022-05-17 16:22  5%     ` Max Nikulin
  2022-05-17 17:56  8%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-05-17 16:22 UTC (permalink / raw)
  To: emacs-orgmode

On 16/05/2022 23:05, Juan Manuel Macías wrote:
> Max Nikulin writes:
> 
> Termux is quite interesting (and addictive :-)). Now I am playing with
> Termux-api to send notifications from Emacs/Gnus to Android (with
> gnus-desktop-notifier and the termux-notification command). And also to
> send sms from Emacs and bbdb...

Do termux and emacs build for it have support of D-Bus or notify-send 
binary? The following thread is related to MacOS, but the discussion was 
a bit more general. Android notification may have more features though.

stardiviner to emacs-orgmode. [PATCH] make org-notify support for macOS 
desktop notification. Sun, 4 Jul 2021 08:23:03 +0800. 
https://list.orgmode.org/5B57CD8B-AA91-4C63-A449-A07364083AEE@gmail.com

I have not tried termux, but I agree that it is an interesting project. 
Unfortunately it is against various policies (only binaries from the 
application package are allowed, even access to filesystem is considered 
unsafe, etc.). Unsure if it is possible to implement a kind of 
virtualization to hide processes from the host system but to keep 
integration with platform. Unfortunately during struggle with 
applications requiring unreasonable permissions and with malware, 
legitimate applications suffer as well (e.g. KDE Connect).



^ permalink raw reply	[relevance 5%]

* Re: [tip] Export and open a PDF in Android via Termux
  2022-05-17 16:22  5%     ` Max Nikulin
@ 2022-05-17 17:56  8%       ` Juan Manuel Macías
  2022-05-18 16:14  6%         ` Max Nikulin
  2022-05-19  9:40  6%         ` Eric S Fraga
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-17 17:56 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

Max Nikulin writes:

> Do termux and emacs build for it have support of D-Bus or notify-send
> binary?

I'm not sure, but I would say yes, because Termux has a repository for
X11 applications and to be able to run desktop environments and
graphical applications (via VNC). But in such a case, I understand that
notify-send would only have life within that frame.

Full GNU/Linux distros can also be installed on termux in a proot
environment. In fact, there is another application, andronix, which
speeds up the process through a series of scripts. Recently I tried
to install using Arch and it worked fine (at least in the installation,
another thing is what can be done in there...).

Anyway, I agree with you about the caveats you mention around termux.
Termux and those other neighboring projects are very notable but they
are still (to put it in some way) juggling games and tightrope walks
without a net. A year ago I made the decision not to use a smartphone,
but lately I have been forced to go back to these devices for work
reasons, so I thought of Termux as the foreigner who is in a strange
land and finds something familiar :- ) The ideal would be a smartphone
running GNU/Linux, but there seems to be a long way to go: hostile
hardware, no drivers... I'm more or less aware of projects like librem
or pinephone, but I'm too lazy to do the disbursement...

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: [tip] Export and open a PDF in Android via Termux
  2022-05-17 17:56  8%       ` Juan Manuel Macías
@ 2022-05-18 16:14  6%         ` Max Nikulin
  2022-05-19  9:40  6%         ` Eric S Fraga
  1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2022-05-18 16:14 UTC (permalink / raw)
  To: emacs-orgmode

On 18/05/2022 00:56, Juan Manuel Macías wrote:
> Max Nikulin writes:
> 
>> Do termux and emacs build for it have support of D-Bus or notify-send
>> binary?
> 
> I'm not sure, but I would say yes, because Termux has a repository for
> X11 applications and to be able to run desktop environments and
> graphical applications (via VNC). But in such a case, I understand that
> notify-send would only have life within that frame.

I expected some drop-in replacement for notify-send that creates native 
android notifications might exist
https://github.com/termux/termux-packages/issues/9923

or even more generally an implementation of d-bus server that is 
interface to android API
https://specifications.freedesktop.org/notification-spec/latest/ar01s09.html



^ permalink raw reply	[relevance 6%]

* Re: [tip] Export and open a PDF in Android via Termux
  2022-05-17 17:56  8%       ` Juan Manuel Macías
  2022-05-18 16:14  6%         ` Max Nikulin
@ 2022-05-19  9:40  6%         ` Eric S Fraga
  2022-05-19 18:01  8%           ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Eric S Fraga @ 2022-05-19  9:40 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On Tuesday, 17 May 2022 at 17:56, Juan Manuel Macías wrote:
> but lately I have been forced to go back to these devices for work
> reasons, so I thought of Termux as the foreigner who is in a strange

Same with me.  I have to have a smartphone as our institution made the
decision to remove all landlines and have all staff use MS Teams as our
work "phone".  I use termux to give me access to Emacs + org so that I
at least get some real use out of the "smart"phone.

-- 
: Eric S Fraga, with org release_9.5.3-504-gcdbb1c in Emacs 29.0.50


^ permalink raw reply	[relevance 6%]

* Re: [tip] Export and open a PDF in Android via Termux
  2022-05-19  9:40  6%         ` Eric S Fraga
@ 2022-05-19 18:01  8%           ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-19 18:01 UTC (permalink / raw)
  To: Eric S Fraga; +Cc: orgmode

Eric S Fraga writes:

> Same with me.  I have to have a smartphone as our institution made the
> decision to remove all landlines and have all staff use MS Teams as our
> work "phone".  I use termux to give me access to Emacs + org so that I
> at least get some real use out of the "smart"phone.

Smartphones are the opium of the 21st century... And worst of all, they
will become the new identity cards. For example, until recently I could
do transactions with my bank through its website. But now it is
mandatory to have a smartphone and download an application, of course
proprietary.

Anyway, termux and Emacs, without a physical keyboard, is torture. I
usually connect a compact mechanical keyboard that I have for my laptop.

By the way, I've noticed how easy it is to write Elisp functions that
call Termux commands from Emacs. I recently wrote this to send SMS (you
can enter the phone number directly or choose a contact saved in BBDB
data base, if you use BBDB). To see the list of contacts it works better
if you use also some completion framework like ivy or helm:

(defun send-sms ()
  (interactive)
  (save-window-excursion (bbdb ".+"))
  (let* ((tlf (if (yes-or-no-p "Enter a contact: ")
		  (let ((record (bbdb-get-records "Contact: ")))
		    (aref
		     (car (aref (car record) 5)) 1))
		(read-from-minibuffer "Phone number: ")))
	 (sms (read-from-minibuffer "Texto del SMS: "))
	 (cmd (format "termux-sms-send -n %s %s" tlf sms)))
    (call-process-shell-command cmd)))

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 8%]

* About 'inline special blocks'
@ 2022-05-23 14:30  8% Juan Manuel Macías
  2022-05-23 15:20  4% ` Kaushal Modi
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-23 14:30 UTC (permalink / raw)
  To: orgmode

Hi all,

I think this idea was suggested by Ihor in a thread from a few months
ago (I don't remember which one), but since other topics were discussed,
the idea remained a bit in limbo. I still find the idea very
interesting, and I think it would be very productive for Org to have a
multipurpose inline container, so it occurred to me to open this thread
to invite a possible discussion on the subject.

I suppose it would have been more practical to start the thread directly
proposing a patch, but since it is about adding a new element to Org,
which is not trivial, I thought that maybe it would be more convenient
to have a previous discussion and poll the users' and developers opinion.

The question is: Does Org Mode need inline special blocks? On the one
hand, it seems that we can live without them. Macros and links can work
competently for this purpose. But macros have the drawback of the comma
as an escape character; and links also have its drawbacks, although the
org-link-set-parameters function is very versatile. And even a huge fan
of links like me can recognize these limitations :-). For example, we
cannot put a footnote inside a link.

Therefore, I think that inline special blocks would fill an important
gap. They could be translated into HTML as a <span></span> container; to
odt as character styles or to LaTeX as commands with arguments. And they
would open the doors to a real solution for multilingual support in Org.

Perhaps the syntax could be a continuation of that of inline code
blocks. Something like:

<name>_[options]{text}

And in options include some 'jibarized' version of attr_latex,
attr_html, etc.

Well, I don't know if I have managed to sell the product well or if I
have been too abstract :-)

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: About 'inline special blocks'
  2022-05-23 14:30  8% About 'inline special blocks' Juan Manuel Macías
@ 2022-05-23 15:20  4% ` Kaushal Modi
  2022-05-23 21:06  9%   ` Juan Manuel Macías
  2022-06-19 12:47  7%   ` Juan Manuel Macías
  0 siblings, 2 replies; 200+ results
From: Kaushal Modi @ 2022-05-23 15:20 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On Mon, May 23, 2022 at 10:33 AM Juan Manuel Macías
<maciaschain@posteo.net> wrote:

> I think this idea was suggested by Ihor in a thread from a few months
> ago (I don't remember which one), but since other topics were discussed,
> the idea remained a bit in limbo. I still find the idea very
> interesting, and I think it would be very productive for Org to have a
> multipurpose inline container, so it occurred to me to open this thread
> to invite a possible discussion on the subject.

Thanks for doing this. I missed that thread. I would welcome this
feature addition too.

If I understand correctly, this will mean adding a new element type
that all the Org exporters can then support. Right?

> The question is: Does Org Mode need inline special blocks?

Yes.

> On the one hand, it seems that we can live without them.

Not quite. I developed few hacks in ox-hugo to make regular special
blocks act like special inline blocks :D

Example:

=====
More than the visual inaccuracy of seeing curved quoted where straight
quotes should be,
#+begin_mark
if someone copies that code to try it out, it will
not work
#+end_mark
!
=====

Another example:

=====
By the way, I submitted a patch for fixing the escaping of straight
quotes in ~shortdoc-add-function~ documentation string
#+begin_sidenote
I planned to fix just this straight quote escaping issue, but then I
also ended up slightly improving the documentation of the ~(FUNC :eval
EVAL)~ and other forms used for adding a function's documentation to
~shortdoc~.
#+end_sidenote
in ..
=====

ox-hugo does the job of deleting the newlines and white-space (leaving
just 1) before and after few "special" special Org blocks.


> Therefore, I think that inline special blocks would fill an important
> gap. They could be translated into HTML as a <span></span> container;

+1

> Perhaps the syntax could be a continuation of that of inline code
> blocks. Something like:
>
> <name>_[options]{text}

The challenging part will be deciding the syntax so that there are no
false matches.

May be reserve "inline_" for inline blocks?

e.g. inline_<name>[options]{text}  ?

Using my example above, if I want the <mark> elements in HTML, I would do

abc inline_mark{some text} def

and that would export to below for an HTML based exporter:

abc <mark>some text</mark> def


^ permalink raw reply	[relevance 4%]

* Re: About 'inline special blocks'
  2022-05-23 15:20  4% ` Kaushal Modi
@ 2022-05-23 21:06  9%   ` Juan Manuel Macías
  2022-05-24  2:36  6%     ` Tim Cross
  2022-06-19 12:47  7%   ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-23 21:06 UTC (permalink / raw)
  To: Kaushal Modi; +Cc: orgmode

Hi, Kaushal, thanks for all your interesting comments,

Kaushal Modi writes:

> The challenging part will be deciding the syntax so that there are no
> false matches.
>
> May be reserve "inline_" for inline blocks?
>
> e.g. inline_<name>[options]{text}  ?

It seems to me the most consistent option, if we continue in some way
the syntax of the inline code blocks, which would be the close relatives
of the inline special blocks. Perhaps (to shorten the syntax a bit)
'inline' could be replaced by some reserved symbol. Something like:

&_<name>[options]{text}

I think a major issue would also be how to properly compact <[options]>
so as not to result in too overloaded syntax. Maybe something like:

[latex(list of attributes) html(list of attributes)...]

?

But that is an abuse of direct formatting, which I think should always be
avoided, especially in a format-agnostic environment like Org, which is
more of a logician than a typesetter :-)

And, in any case, it is to be expected that the user will not need to
overload that part, since these hypothetical inline blocks would be
intended for short segments of text within the paragraph. I think the
most typical use case would be something like your 'mark' example.

Best regards,

Juan Manuel 




^ permalink raw reply	[relevance 9%]

* Re: About 'inline special blocks'
  2022-05-23 21:06  9%   ` Juan Manuel Macías
@ 2022-05-24  2:36  6%     ` Tim Cross
    0 siblings, 1 reply; 200+ results
From: Tim Cross @ 2022-05-24  2:36 UTC (permalink / raw)
  To: emacs-orgmode


I've not got a lot to add here. I'm not against the idea, but Juan makes
some points below which I think are particularly important and wanted to
add weight to them!

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

> Hi, Kaushal, thanks for all your interesting comments,
>
> Kaushal Modi writes:
>
>> The challenging part will be deciding the syntax so that there are no
>> false matches.
>>
>> May be reserve "inline_" for inline blocks?
>>
>> e.g. inline_<name>[options]{text}  ?
>
> It seems to me the most consistent option, if we continue in some way
> the syntax of the inline code blocks, which would be the close relatives
> of the inline special blocks. Perhaps (to shorten the syntax a bit)
> 'inline' could be replaced by some reserved symbol. Something like:
>
> &_<name>[options]{text}
>

I agree. Selection of the 'symbol' might be tricky, but the idea is
sound.


> I think a major issue would also be how to properly compact <[options]>
> so as not to result in too overloaded syntax. Maybe something like:
>
> [latex(list of attributes) html(list of attributes)...]
>
> ?
>
> But that is an abuse of direct formatting, which I think should always be
> avoided, especially in a format-agnostic environment like Org, which is
> more of a logician than a typesetter :-)

I think this is a really important point. Whenever we add formatting
specific directives, we always end up in a somewhat uncertain situation
with respect to the other back ends. I also feel that in-line blocks
which support large and complex formatting configuration really defeat
the purpose of an in=line block (which I feel should be kept relatively
simple). I also find complex constructs of this form really degrades the
readability of source documents. 

>
> And, in any case, it is to be expected that the user will not need to
> overload that part, since these hypothetical inline blocks would be
> intended for short segments of text within the paragraph. I think the
> most typical use case would be something like your 'mark' example.
>

Yes, that was my thinking as well. 




^ permalink raw reply	[relevance 6%]

* Re: About 'inline special blocks'
  @ 2022-05-25 13:55 10%         ` Juan Manuel Macías
    1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-25 13:55 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> I think that we might simply allow to define complex configuration
> before the containing paragraph. Something like:
>
> #+attr_latex[name]: <complex config goes here>
> Vestibulum convallis, lorem blockname_[<<name>>]{text} a tempus semper, dui
> dui euismod elit, vitae placerat urna tortor vitae lacus.
>
> "<<name>>" will be treated as "<complex config goes here>" during
> export/parsing.

I really like this idea of taking the complex configuration (in case it
is needed) out of the paragraph. I vote for a procedure of this style.
That rows in favor of legibility and lightness. Of course, the blocks
that need an /ad hoc/ configuration represent, in my opinion, an extreme
use case; and, as I mentioned before, I think that it should be avoided
as much as possible. I also fully agree with Tim's comments on this.
Ideally, any format settings for LaTeX, odt, html, etc. must be done
globally, outside the body.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* [tip] org-publish to work with (very) large books
@ 2022-05-26 10:01  5% Juan Manuel Macías
  2022-05-26 12:46  6% ` Christian Moe
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-26 10:01 UTC (permalink / raw)
  To: orgmode

Hi all,

- tl; dr: I describe here my workflow with org-publish to work with long
books.

—

I discovered a long time ago that `org-publish' not only works very well
for managing websites but also for working with long and complex books
with many parts, with output to LaTeX/PDF. I developed a workflow around
it that has been quite productive for me, and that I briefly describe
here in case someone finds it useful and wants to try it or modify/adapt
it to their needs. I usually use it for my typesetting work, but I think
it can also be useful for personal projects, such as doctoral theses.

First of all, each folder of my project-books has the same structure:
two subdirectories named `/org' and `/tex', for the source `org' files
and for the output `.tex' documents, respectively. And, inside the `org'
directory I include a `setup' file, an `elisp' file (for export
filters), and another `/img' directory for image files. Each `org' file
is a part of the book, and usually begins simply with the directives:

┌────
│ #+SETUPFILE: xxx.setup
│ #+INCLUDE: "elisp"
└────

`Org-publish' exports the subdocuments (body only!) as `.tex' documents
in the `/tex' folder, but they are not compiled.

What gets compiled is a master `.org' file, which is also inside the
`org' folder. I compile this master file using an asynchronous function
that calls `latexmk'. I put all the LaTeX configuration, the packages to
load, the (re)defined commands and macros, the necessary Lua code, etc.
in a `.sty' file that I load at the very beginning of the master
document. Subdocuments are loaded into this file by the LaTeX command
(\input), not by the org #+INCLUDE directive. So the master file usually
looks like this:

┌────
│ #+LaTeX_CLASS: my-custom-latex-class
│ #+LaTeX_Header: \input{my-custom-conf.sty}
│ #+SETUPFILE: xxxx.setup
│ #+INCLUDE: "elisp"
│ 
│ * Part 1
│ ** Chapter 1
│ #+LaTeX: \input{chapter1.tex}
└────

When I eval my function, `latexmk' compiles the entire book with the
`-pvc' option, which keeps the session open, and if it detects any
changes to the entire document, it recompiles and refresh the pdf view.
For example, if I edit one of the subdocuments and run
`org-publish-current-file', everything is automatically recompiled.

When I have the project folder ready, I add this to
`org-publish-project-alist' (this is an example from one of the books I
did recently):

┌────
│ ("cartas-org"
│  :base-directory "~/Git/cartas/libro/org/"
│  :base-extension "org"
│  ;; Directorio para los ficheros *.tex
│  :publishing-directory "~/Git/cartas/libro/tex/"
│  :publishing-function org-latex-publish-to-latex
│  :body-only t ;; this is important!
│  :exclude "cartas-master\\.org\\|bibliografia-cartas\\.org"
│  :recursive t)
│ 
│ ("cartas-img"
│  :base-directory "~/Git/cartas/libro/org/img/"
│  :base-extension "jpg\\|png"
│  :publishing-directory "~/Git/cartas/libro/tex/img/"
│  :recursive t
│  :publishing-function org-publish-attachment)
│ 
│ ("cartas" :components ("cartas-tex" "cartas-img"))
└────

And finally, this is the function that compiles everything (each project
usually has some local variables, like the value of ’jobname’ or the
status of the printing proofs).

Nota Bene: The reason for using async is that in some projects,
especially bilingual editions, I need to pre-compile some files first.
Under normal conditions I don't think it's necessary to use async, since
org-publish just exports everything to .tex documents (short timeout)
and then start-process-shell-command run latexmk asynchronously.

Best regards,

Juan Manuel 

┌────
│ (require 'async)
│ (require 'projectile)
│ 
│ (defun latexmk-compile-project-async ()
│   (interactive)
│   (let*
│       ((project-root (projectile-project-root))
│        (master-file (read-file-name "Compile: "
│ 				    (concat project-root "libro/org/")))
│        (master-file-tex (file-name-sans-extension
│ 			 (expand-file-name master-file)))
│        (dir-tex (file-name-directory
│ 		 (expand-file-name
│ 		  (replace-regexp-in-string "/org/" "/tex/" master-file)))))
│     ;; save the master document
│     (with-current-buffer
│ 	(find-file-noselect master-file)
│       (save-buffer))
│     (async-start
│      (lambda ()
│        (load "~/.emacs")
│        (with-current-buffer
│ 	   (find-file-noselect master-file)
│ 	 (org-show-all)
│ 	 (save-buffer)
│ 	 (org-latex-export-to-latex nil nil nil nil nil))
│        ;; remove all old auxiliary files before compiling
│        (shell-command (concat "rm -r " dir-tex (file-name-base master-file-tex) "*"))
│        (shell-command (concat "mv " master-file-tex ".tex" " " dir-tex))
│        "Document exported")
│      (lambda (resultado)
│        (message resultado)
│        (let
│ 	   ((default-directory dir-tex)
│ 	    (jobname (if (and jobname-local printing-proofs-state)
│ 			 (concat jobname-local "_" printing-proofs-state "_"
│ 				 (format-time-string "%d-%m-%y"))
│ 		       (concat (file-name-sans-extension
│ 				(file-name-nondirectory master-file-tex))
│ 			       "_"
│ 			       (format-time-string "%d-%m-%y")))))
│ 	 (start-process-shell-command
│ 	  "project"
│ 	  "*project*"
│ 	  (concat
│ 	   "latexmk"
│ 	   " -jobname="
│ 	   jobname
│ 	   " -pvc -lualatex -e '$lualatex=q/lualatex %O -shell-escape %S/' "
│ 	   (file-name-nondirectory master-file-tex)
│ 	   ".tex")))))))
└────


^ permalink raw reply	[relevance 5%]

* Re: [tip] org-publish to work with (very) large books
  2022-05-26 10:01  5% [tip] org-publish to work with (very) large books Juan Manuel Macías
@ 2022-05-26 12:46  6% ` Christian Moe
    0 siblings, 1 reply; 200+ results
From: Christian Moe @ 2022-05-26 12:46 UTC (permalink / raw)
  To: emacs-orgmode


Thanks for this, really interesting.

Do I understand correctly that the main advantage of this approach (over
#+INCLUDE) is the ability to continuously update preview of the whole
book with latexmk -pvc even if you only re-export one chapter from
Org-mode?

I couldn't find the :body-only publishing option in the docs ...?

Yours,
Christian

Juan Manuel Macías writes:

> Hi all,
>
> - tl; dr: I describe here my workflow with org-publish to work with long
> books.
>
> —
>
> I discovered a long time ago that `org-publish' not only works very well
> for managing websites but also for working with long and complex books
> with many parts, with output to LaTeX/PDF. I developed a workflow around
> it that has been quite productive for me, and that I briefly describe
> here in case someone finds it useful and wants to try it or modify/adapt
> it to their needs. I usually use it for my typesetting work, but I think
> it can also be useful for personal projects, such as doctoral theses.
>
> First of all, each folder of my project-books has the same structure:
> two subdirectories named `/org' and `/tex', for the source `org' files
> and for the output `.tex' documents, respectively. And, inside the `org'
> directory I include a `setup' file, an `elisp' file (for export
> filters), and another `/img' directory for image files. Each `org' file
> is a part of the book, and usually begins simply with the directives:
>
> ┌────
> │ #+SETUPFILE: xxx.setup
> │ #+INCLUDE: "elisp"
> └────
>
> `Org-publish' exports the subdocuments (body only!) as `.tex' documents
> in the `/tex' folder, but they are not compiled.
>
> What gets compiled is a master `.org' file, which is also inside the
> `org' folder. I compile this master file using an asynchronous function
> that calls `latexmk'. I put all the LaTeX configuration, the packages to
> load, the (re)defined commands and macros, the necessary Lua code, etc.
> in a `.sty' file that I load at the very beginning of the master
> document. Subdocuments are loaded into this file by the LaTeX command
> (\input), not by the org #+INCLUDE directive. So the master file usually
> looks like this:
>
> ┌────
> │ #+LaTeX_CLASS: my-custom-latex-class
> │ #+LaTeX_Header: \input{my-custom-conf.sty}
> │ #+SETUPFILE: xxxx.setup
> │ #+INCLUDE: "elisp"
> │
> │ * Part 1
> │ ** Chapter 1
> │ #+LaTeX: \input{chapter1.tex}
> └────
>
> When I eval my function, `latexmk' compiles the entire book with the
> `-pvc' option, which keeps the session open, and if it detects any
> changes to the entire document, it recompiles and refresh the pdf view.
> For example, if I edit one of the subdocuments and run
> `org-publish-current-file', everything is automatically recompiled.
>
> When I have the project folder ready, I add this to
> `org-publish-project-alist' (this is an example from one of the books I
> did recently):
>
> ┌────
> │ ("cartas-org"
> │  :base-directory "~/Git/cartas/libro/org/"
> │  :base-extension "org"
> │  ;; Directorio para los ficheros *.tex
> │  :publishing-directory "~/Git/cartas/libro/tex/"
> │  :publishing-function org-latex-publish-to-latex
> │  :body-only t ;; this is important!
> │  :exclude "cartas-master\\.org\\|bibliografia-cartas\\.org"
> │  :recursive t)
> │
> │ ("cartas-img"
> │  :base-directory "~/Git/cartas/libro/org/img/"
> │  :base-extension "jpg\\|png"
> │  :publishing-directory "~/Git/cartas/libro/tex/img/"
> │  :recursive t
> │  :publishing-function org-publish-attachment)
> │
> │ ("cartas" :components ("cartas-tex" "cartas-img"))
> └────
>
> And finally, this is the function that compiles everything (each project
> usually has some local variables, like the value of ’jobname’ or the
> status of the printing proofs).
>
> Nota Bene: The reason for using async is that in some projects,
> especially bilingual editions, I need to pre-compile some files first.
> Under normal conditions I don't think it's necessary to use async, since
> org-publish just exports everything to .tex documents (short timeout)
> and then start-process-shell-command run latexmk asynchronously.
>
> Best regards,
>
> Juan Manuel
>
> ┌────
> │ (require 'async)
> │ (require 'projectile)
> │
> │ (defun latexmk-compile-project-async ()
> │   (interactive)
> │   (let*
> │       ((project-root (projectile-project-root))
> │        (master-file (read-file-name "Compile: "
> │ 				    (concat project-root "libro/org/")))
> │        (master-file-tex (file-name-sans-extension
> │ 			 (expand-file-name master-file)))
> │        (dir-tex (file-name-directory
> │ 		 (expand-file-name
> │ 		  (replace-regexp-in-string "/org/" "/tex/" master-file)))))
> │     ;; save the master document
> │     (with-current-buffer
> │ 	(find-file-noselect master-file)
> │       (save-buffer))
> │     (async-start
> │      (lambda ()
> │        (load "~/.emacs")
> │        (with-current-buffer
> │ 	   (find-file-noselect master-file)
> │ 	 (org-show-all)
> │ 	 (save-buffer)
> │ 	 (org-latex-export-to-latex nil nil nil nil nil))
> │        ;; remove all old auxiliary files before compiling
> │        (shell-command (concat "rm -r " dir-tex (file-name-base master-file-tex) "*"))
> │        (shell-command (concat "mv " master-file-tex ".tex" " " dir-tex))
> │        "Document exported")
> │      (lambda (resultado)
> │        (message resultado)
> │        (let
> │ 	   ((default-directory dir-tex)
> │ 	    (jobname (if (and jobname-local printing-proofs-state)
> │ 			 (concat jobname-local "_" printing-proofs-state "_"
> │ 				 (format-time-string "%d-%m-%y"))
> │ 		       (concat (file-name-sans-extension
> │ 				(file-name-nondirectory master-file-tex))
> │ 			       "_"
> │ 			       (format-time-string "%d-%m-%y")))))
> │ 	 (start-process-shell-command
> │ 	  "project"
> │ 	  "*project*"
> │ 	  (concat
> │ 	   "latexmk"
> │ 	   " -jobname="
> │ 	   jobname
> │ 	   " -pvc -lualatex -e '$lualatex=q/lualatex %O -shell-escape %S/' "
> │ 	   (file-name-nondirectory master-file-tex)
> │ 	   ".tex")))))))
> └────


^ permalink raw reply	[relevance 6%]

* Re: [tip] org-publish to work with (very) large books
  @ 2022-05-26 13:48  8%     ` Juan Manuel Macías
  2022-05-26 17:47  6%       ` Christian Moe
  2022-05-27  4:19  6%       ` Ihor Radchenko
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-26 13:48 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Christian Moe, orgmode

Hi Ihor and Christian,

Ihor Radchenko writes:

> Christian Moe <mail@christianmoe.com> writes:
>
>> Do I understand correctly that the main advantage of this approach (over
>> #+INCLUDE) is the ability to continuously update preview of the whole
>> book with latexmk -pvc even if you only re-export one chapter from
>> Org-mode?
>
> I am not sure why Juan did not use include. Include would not require
> LaTeX to re-compile unchanged files. See
> https://tex.stackexchange.com/questions/246/when-should-i-use-input-vs-include
>
>> I couldn't find the :body-only publishing option in the docs ...?
>
> See [[info:org#The Export Dispatcher][org#The Export Dispatcher]]
>
> Best,
> Ihor
>

Sorry for not explaining the \input part in more detail. I think the
essential part here is that all the .tex files (the subdocuments) are
already created by org-publish before I compile the master document. The
master document simply stores all the subdocuments: I use
\input{subdocument.tex} instead of the org #+INCLUDE directive (not the
LaTeX \include command). The master document calls ready-made TeX files,
not Org files. And it is independent of the whole org-publish process,
which is responsible for creating only the parts of the book. This
procedure, apart from being able to compile parts of the book in real
time with latexmk -pvc, allows me to have more control over these parts.
But it makes more sense to use it when dealing with very long books. The
first time I used it was in a book of more than 1000 pages :-)

The skeleton of the process is that subdocuments are produced with
org-publish (as uncompiled tex files) and the master document is
exported to tex from org and then compiled with latexmk inside /tex
directory.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: [tip] org-publish to work with (very) large books
  2022-05-26 13:48  8%     ` Juan Manuel Macías
@ 2022-05-26 17:47  6%       ` Christian Moe
  2022-05-27  4:19  6%       ` Ihor Radchenko
  1 sibling, 0 replies; 200+ results
From: Christian Moe @ 2022-05-26 17:47 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Ihor Radchenko, Christian Moe, orgmode


Thanks, Juan!

Yours,
Christian

Juan Manuel Macías writes:

> Hi Ihor and Christian,
>
> Ihor Radchenko writes:
>
>> Christian Moe <mail@christianmoe.com> writes:
>>
>>> Do I understand correctly that the main advantage of this approach (over
>>> #+INCLUDE) is the ability to continuously update preview of the whole
>>> book with latexmk -pvc even if you only re-export one chapter from
>>> Org-mode?
>>
>> I am not sure why Juan did not use include. Include would not require
>> LaTeX to re-compile unchanged files. See
>> https://tex.stackexchange.com/questions/246/when-should-i-use-input-vs-include
>>
>>> I couldn't find the :body-only publishing option in the docs ...?
>>
>> See [[info:org#The Export Dispatcher][org#The Export Dispatcher]]
>>
>> Best,
>> Ihor
>>
>
> Sorry for not explaining the \input part in more detail. I think the
> essential part here is that all the .tex files (the subdocuments) are
> already created by org-publish before I compile the master document. The
> master document simply stores all the subdocuments: I use
> \input{subdocument.tex} instead of the org #+INCLUDE directive (not the
> LaTeX \include command). The master document calls ready-made TeX files,
> not Org files. And it is independent of the whole org-publish process,
> which is responsible for creating only the parts of the book. This
> procedure, apart from being able to compile parts of the book in real
> time with latexmk -pvc, allows me to have more control over these parts.
> But it makes more sense to use it when dealing with very long books. The
> first time I used it was in a book of more than 1000 pages :-)
>
> The skeleton of the process is that subdocuments are produced with
> org-publish (as uncompiled tex files) and the master document is
> exported to tex from org and then compiled with latexmk inside /tex
> directory.
>
> Best regards,
>
> Juan Manuel 



^ permalink raw reply	[relevance 6%]

* Re: [tip] org-publish to work with (very) large books
  2022-05-26 13:48  8%     ` Juan Manuel Macías
  2022-05-26 17:47  6%       ` Christian Moe
@ 2022-05-27  4:19  6%       ` Ihor Radchenko
  2022-05-27 11:39  8%         ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-27  4:19 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Christian Moe, orgmode

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

> Sorry for not explaining the \input part in more detail. I think the
> essential part here is that all the .tex files (the subdocuments) are
> already created by org-publish before I compile the master document. The
> master document simply stores all the subdocuments: I use
> \input{subdocument.tex} instead of the org #+INCLUDE directive (not the
> LaTeX \include command). The master document calls ready-made TeX files,
> not Org files. And it is independent of the whole org-publish process,
> which is responsible for creating only the parts of the book.

> This
> procedure, apart from being able to compile parts of the book in real
> time with latexmk -pvc, allows me to have more control over these parts.
> But it makes more sense to use it when dealing with very long books. The
> first time I used it was in a book of more than 1000 pages :-)

I am not sure if I understand correctly. Do you mean that you only
preview the book parts you are currently working on via latexmk -pvc?
What kind of more control are you referring to?

Best,
Ihor



^ permalink raw reply	[relevance 6%]

* Re: [tip] org-publish to work with (very) large books
  2022-05-27  4:19  6%       ` Ihor Radchenko
@ 2022-05-27 11:39  8%         ` Juan Manuel Macías
  2022-05-28  3:02  5%           ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-27 11:39 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> I am not sure if I understand correctly. Do you mean that you only
> preview the book parts you are currently working on via latexmk -pvc?
> What kind of more control are you referring to?

The -pvc flag means that if latexmk detects any modification to any
document involved in the current job (a subdocument, the .sty file, a
.bib file, or whatever), it reruns the appropriate builds to bring the
pdf up to date, and it only stops when everything is up to date. I can
focus that action on parts of the book by commenting or uncommenting
elements in the master file.

The moment one breaks down a large piece of work into specialized parts,
one gains more control over that piece of work. And org-publish helps
manage all of that. It is about managing a large book as a website (via
org-publish). In short, the combination of org-publish, projectile and
latexmk is quite productive for me in this type of work.

Anyway, as they say that a picture is worth a thousand words, I have
made this short example video. This is a dictionary I produced a year
ago. Each dictionary entry has its own separate bibliographic list, so I
had to manage more than 100 separate bib files. I have all these files
inside an Org document, and I create them using org-babel-tangle. The
video shows editing a field in a bib file. I've removed the build time
from the video, as the entire book is almost a thousand pages long.

https://cloud.disroot.org/s/PiSaHqWZr25GfJY

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: how to export an org file, to 2 different locations (in to different formats)
  @ 2022-05-27 18:42  9% ` Juan Manuel Macías
  2022-05-28  0:18 10%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-27 18:42 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode

Hi Uwe,

Uwe Brauer writes:

> Hi
>
> Currently I use 
> #+EXPORT_FILE_NAME: /home/oub/Desktop/some-stuff.html
>
> To export my org file in html format to that location.
>
> But I would also like to export it as a latex file to a different
> location, without modifying the above line, or to be more precise to add
> a different location, like
>
>     1. if export to latex use that folder
>
>     2. If export to html use this folder
>
> Anybody know about such a functionality?
>
> Thanks and regards
>
> Uwe Brauer 

One (pedestrian) way to achieve it, with this function:

(defun my-org/export-to-path (backend export-path extension)
  (org-element-map (org-element-parse-buffer) 'keyword
    (lambda (k)
      (when (string= (org-element-property :key k) "EXPORT_FILE_NAME")
	(let ((value (org-element-property :value k)))
	  (org-export-to-file backend
	      (format
	       "%s%s.%s"
	       export-path
	       value extension)))))))

And then you could evaluate it inside a block in your document, with the
chosen arguments. For example:

#+EXPORT_FILE_NAME: myfile

#+begin_src emacs-lisp :exports none :eval never-export :results silent
  (my-org/export-to-path 'html "~/Desktop/" "html")
#+end_src

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: how to export an org file, to 2 different locations (in to different formats)
  2022-05-27 18:42  9% ` Juan Manuel Macías
@ 2022-05-28  0:18 10%   ` Juan Manuel Macías
  2022-05-28  6:36  0%     ` Uwe Brauer
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-28  0:18 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode

Juan Manuel Macías writes:

> One (pedestrian) way to achieve it, with this function:

I think it can be done better this way, defining an advice around
'org-export-output-file-name'.

In your org file you should add these two local variables:

# my-latex-export-path: "~/path/to/myfile.tex"
# my-html-export-path "~/path/to/myfile.html"

And this is the define-advice code. It should export to one or another path/file every
time you export your document to LaTeX or html. I haven't tried it much:

(define-advice org-export-output-file-name (:around (old-func extension &rest args))
  (setq old-func (lambda (extension &optional subtreep pub-dir)
		   (let* ((visited-file (buffer-file-name (buffer-base-buffer)))
			  (base-name
			   (concat
			    (file-name-sans-extension
			     (or
			      ;; Check EXPORT_FILE_NAME subtree property.
			      (and subtreep (org-entry-get nil "EXPORT_FILE_NAME" 'selective))
			      ;; Check #+EXPORT_FILE_NAME keyword.
			      (org-with-point-at (point-min)
				(catch :found
				  (let ((case-fold-search t))
				    (while (re-search-forward
					    "^[ \t]*#\\+EXPORT_FILE_NAME:[ \t]+\\S-" nil t)
				      (let ((element (org-element-at-point)))
					(when (eq 'keyword (org-element-type element))
					  (throw :found
						 (org-element-property :value element))))))))
			      ;; Extract from buffer's associated file, if any.
			      (and visited-file
				   (file-name-nondirectory
				    ;; For a .gpg visited file, remove the .gpg extension:
				    (replace-regexp-in-string "\\.gpg\\'" "" visited-file)))
			      ;; Can't determine file name on our own: ask user.
			      (read-file-name
			       "Output file: " pub-dir nil nil nil
			       (lambda (n) (string= extension (file-name-extension n t))))))
			    extension))
			  (output-file
			   ;; Build file name.  Enforce EXTENSION over whatever user
			   ;; may have come up with.  PUB-DIR, if defined, always has
			   ;; precedence over any provided path.
			   (cond
			    (pub-dir (concat (file-name-as-directory pub-dir)
					     (file-name-nondirectory base-name)))
			    ((file-name-absolute-p base-name) base-name)
			    (t base-name))))
		     ;; If writing to OUTPUT-FILE would overwrite original file, append
		     ;; EXTENSION another time to final name.
		     (if (and visited-file (file-equal-p visited-file output-file))
			 (concat output-file extension)
		       output-file))))
  (if (and my-latex-export-path my-html-export-path)
      (cond ((equal extension ".tex")
	     my-latex-export-path)
	    ((equal extension ".html")
	     my-html-export-path))
    (apply old-func args)))

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [tip] org-publish to work with (very) large books
  2022-05-27 11:39  8%         ` Juan Manuel Macías
@ 2022-05-28  3:02  5%           ` Ihor Radchenko
  2022-05-28  8:59  6%             ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-28  3:02 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> Ihor Radchenko writes:
>
>> I am not sure if I understand correctly. Do you mean that you only
>> preview the book parts you are currently working on via latexmk -pvc?
>> What kind of more control are you referring to?
>
> The -pvc flag means that if latexmk detects any modification to any
> document involved in the current job (a subdocument, the .sty file, a
> .bib file, or whatever), it reruns the appropriate builds to bring the
> pdf up to date, and it only stops when everything is up to date. I can
> focus that action on parts of the book by commenting or uncommenting
> elements in the master file.

> Anyway, as they say that a picture is worth a thousand words, I have
> made this short example video. This is a dictionary I produced a year
> ago. Each dictionary entry has its own separate bibliographic list, so I
> had to manage more than 100 separate bib files. I have all these files
> inside an Org document, and I create them using org-babel-tangle. The
> video shows editing a field in a bib file. I've removed the build time
> from the video, as the entire book is almost a thousand pages long.
>
> https://cloud.disroot.org/s/PiSaHqWZr25GfJY

Thanks for the clarification! So, you are previewing the whole book with
some \input statements commented out. It is an ok approach, unless you
need cross-references between chapters.

A more advanced approach would be using
\include + \includeonly instead of \input:

https://web.archive.org/web/20160627050806/http://www.howtotex.com/tips-tricks/faster-latex-part-i-compile-only-parts/

Also, FYI:

https://web.archive.org/web/20160712215709/http://www.howtotex.com:80/tips-tricks/faster-latex-part-iv-use-a-precompiled-preamble/

> The moment one breaks down a large piece of work into specialized parts,
> one gains more control over that piece of work. And org-publish helps
> manage all of that. It is about managing a large book as a website (via
> org-publish). In short, the combination of org-publish, projectile and
> latexmk is quite productive for me in this type of work.

This is a bit confusing. You still keep the book in a single giant Org
file. It indeed does not mean anything given that we can always narrow
to subtree, but I fail to see where you break the book into specialized
parts then (LaTeX performance trickery aside).

Best,
Ihor


^ permalink raw reply	[relevance 5%]

* Re: how to export an org file, to 2 different locations (in to different formats)
  2022-05-28  0:18 10%   ` Juan Manuel Macías
@ 2022-05-28  6:36  0%     ` Uwe Brauer
  2022-05-28  7:23  8%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-05-28  6:36 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode

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

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

> Juan Manuel Macías writes:
>> One (pedestrian) way to achieve it, with this function:

> I think it can be done better this way, defining an advice around
> 'org-export-output-file-name'.

> In your org file you should add these two local variables:

> # my-latex-export-path: "~/path/to/myfile.tex"
> # my-html-export-path "~/path/to/myfile.html"

> And this is the define-advice code. It should export to one or another path/file every
> time you export your document to LaTeX or html. I haven't tried it much:


Thanks, that looks even more convenient!
I tried to test it with 

#+begin_example
# my-latex-export-path: "./myfile2.tex"
# my-html-export-path "~/Desktop/myfile2.html"

,#+begin_src emacs-lisp :exports none :eval never-export :results silent
  (my-org/export-to-path 'html "~/Desktop/" "html")
,#+end_src


,#+begin_src emacs-lisp :exports none :eval never-export :results silent
  (my-org/export-to-path 'latex "./" "tex")
,#+end_src

,* Excuses


Jim: Which was? Sir Humphrey: 

#+end_example

When I run it I obtain 
if: Symbol’s value as variable is void: my-latex-export-path

Another point is if I decide to export it to ods, I need to modify that
advice, but I agree the new function is more convenient.

Uwe 

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

^ permalink raw reply	[relevance 0%]

* Re: how to export an org file, to 2 different locations (in to different formats)
  2022-05-28  6:36  0%     ` Uwe Brauer
@ 2022-05-28  7:23  8%       ` Juan Manuel Macías
  2022-05-28  8:40  1%         ` Uwe Brauer
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-28  7:23 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode

Uwe Brauer writes:

> When I run it I obtain 
> if: Symbol’s value as variable is void: my-latex-export-path
>
> Another point is if I decide to export it to ods, I need to modify that
> advice, but I agree the new function is more convenient.

You must add the variables to the document as local variables, at the
end of the document, like this:

# Local Variables:
# my-latex-export-path: "~/path/myfile.tex"
# my-html-export-path: "~/path/myfile.html"
# End:

But (it's important, I didn't tell you, sorry) before you must globally
define the variables with nil value, so that you don't get an error in
other documents:

(setq my-latex-export-path nil
      my-html-export-path nil)

With this 'define-advice' procedure you don't need the other code I gave
you. You can export in the usual way, using the dispatcher. The only
difference is that in any document where these variables exist, the
resulting file will be saved in the directory/name specified in the
variables, depending on whether you export to latex or html.

To add more cases, like odt, simply:

(1) you define a new variable:

  (setq my-latex-export-path nil
	my-html-export-path nil
	my-odt-export-path nil)

and locally:

# Local Variables:
# my-latex-export-path: "~/path/myfile.tex"
# my-html-export-path: "~/path/myfile.html"
# my-odt-export-path: "~/path/myfile.html"
# End:

(2) And you add a new condition at the end of the define-advice:

[...]
(if (and my-latex-export-path
	     my-html-export-path
	     my-odt-export-path)
	(cond ((equal extension ".tex")
	       my-latex-export-path)
	      ((equal extension ".html")
	       my-html-export-path)
	      ((equal extension ".odt")
	       my-odt-export-path))
      (apply old-func args)))

It means that: if those variables exist, it returns as a result the
path/name that you have specified for each case. Otherwise, the
org-export-output-file-name function is executed normally.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: how to export an org file, to 2 different locations (in to different formats)
  2022-05-28  7:23  8%       ` Juan Manuel Macías
@ 2022-05-28  8:40  1%         ` Uwe Brauer
  2022-05-28  9:06 10%           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-05-28  8:40 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode

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

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

> Uwe Brauer writes:
>> When I run it I obtain 
>> if: Symbol’s value as variable is void: my-latex-export-path
>> 
>> Another point is if I decide to export it to ods, I need to modify that
>> advice, but I agree the new function is more convenient.

> You must add the variables to the document as local variables, at the
> end of the document, like this:

> # Local Variables:
> # my-latex-export-path: "~/path/myfile.tex"
> # my-html-export-path: "~/path/myfile.html"
> # End:

Aha, I see, thanks

Just one observation, while this is more convenient your other method has the benefit that it allows me to export to 2 files in different locations having the *same* extension like


> # my-latex-export-path: "~/path/myfile1.tex"
> # my-latex-export-path: "~/path/myfile2.tex"

Which seems more complicated in the other approach. 

I have also to confess, that I usually am I bit hesitant to use defadvice since it changes the vanilla function, and might cause problems, but maybe this is just me.

In any case thanks for both solution, that was very generous and helpful.

Developers: why to include some of this code in a addon file, if Juan agrees of course!

Uwe 


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

^ permalink raw reply	[relevance 1%]

* Re: [tip] org-publish to work with (very) large books
  2022-05-28  3:02  5%           ` Ihor Radchenko
@ 2022-05-28  8:59  6%             ` Juan Manuel Macías
  2022-05-29 12:15  5%               ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-28  8:59 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> A more advanced approach would be using
> \include + \includeonly instead of \input:
>
> https://web.archive.org/web/20160627050806/http://www.howtotex.com/tips-tricks/faster-latex-part-i-compile-only-parts/

Yeah, \include and \includeonly save the .aux files for each part.
However, I think choosing between \input, \include or \includeonly is
not the important part here. I usually use \input for convenience,
because I have not needed in the work done to make references between
parts. You can choose any of the options, according to needs. Also this
procedure can be made more complex. For example, sometimes (when it
comes to a bilingual edition with facing pages), I also start from
precompiled documents together with tex (subdocument) files. The
precompiled documents are placed on the odd and even pages of the
bilingual part:

https://i.imgur.com/Jbjutmf.jpg

> Also, FYI:
>
> https://web.archive.org/web/20160712215709/http://www.howtotex.com:80/tips-tricks/faster-latex-part-iv-use-a-precompiled-preamble/

Using a precompiled preamble can improve compilation sometimes, but
other times it's not worth it. Also, I use a lot of code in Lua. When it
comes to a very complex preamble, with lots of code, it is usually more
practical to create a .sty file (that is, a package, in LaTeX parlance).
The difference is that I prefer to use org and org-babel-tangle instead
of the 'official' LaTeX suite docstript for writing packages, which I
find horribly hard, especially compared to the ease of Org :-)

Improving performance and compile time in TeX is an old topic, and there
are a few tricks here and there. But TeX is what Emacs is, both are
venerably old; and both are single-thread. There are more ''modern''
approaches, like Patoline or Sile (of course, based heavily on TeX,
which is the father of everything). Sile, especially, is very
interesting and from time to time I like to play with it. The problem
with these new projects is that they don't have the LaTeX package
ecosystem, and they are poorly documented. Well, Sile in particular is
the work of a single person. Links:

https://patoline.github.io/#documentation

https://sile-typesetter.org/

As for LuaTeX, which is the state of the art today in the TeX ecosystem,
it is nothing more than TeX + a lua interpreter + the implementation of
advanced features from previous engines like pdfTeX and the experimental
Omega/Alef. It has the advantage that it is a scriptable TeX (TeX
primitives can be controlled by Lua scripts, and truly amazing things[1]
can be achieved with very little effort[2]); it has the disadvantage that
the scripting language is Lua. The ideal would have been a Lisp-TeX ;-)

[1] The chickenize package contains many examples, some of them somewhat
absurd and not very useful in
appearance: https://www.ctan.org/pkg/chickenize

[2] https://tug.org/TUGboat/tb31-3/tb99isambert.pdf

>> The moment one breaks down a large piece of work into specialized parts,
>> one gains more control over that piece of work. And org-publish helps
>> manage all of that. It is about managing a large book as a website (via
>> org-publish). In short, the combination of org-publish, projectile and
>> latexmk is quite productive for me in this type of work.
>
> This is a bit confusing. You still keep the book in a single giant Org
> file. It indeed does not mean anything given that we can always narrow
> to subtree, but I fail to see where you break the book into specialized
> parts then (LaTeX performance trickery aside).

I think this is inaccurate. The book is split across multiple
subdocuments. The master file is just the 'outline' of the book.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 6%]

* Re: how to export an org file, to 2 different locations (in to different formats)
  2022-05-28  8:40  1%         ` Uwe Brauer
@ 2022-05-28  9:06 10%           ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-28  9:06 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode

Uwe Brauer writes:

> I have also to confess, that I usually am I bit hesitant to use
> defadvice since it changes the vanilla function, and might cause
> problems, but maybe this is just me.

You are absolutely right, and I confess that I would have the same
precautions :-). Also, the defadvice code is very poorly tested, and is
likely to cause some collateral kills... If you need it for specific use
cases, you can try evaluating it only for specific sessions, instead of
leaving it in your init file. Or make a mode that turns it on or off.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [tip] org-publish to work with (very) large books
  2022-05-28  8:59  6%             ` Juan Manuel Macías
@ 2022-05-29 12:15  5%               ` Ihor Radchenko
  2022-05-29 18:01  6%                 ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-29 12:15 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> Improving performance and compile time in TeX is an old topic, and there
> are a few tricks here and there. But TeX is what Emacs is, both are
> venerably old; and both are single-thread.

Yet, the information is surprisingly scattered. I was unable to find a
single guide on the available possibilities. Mostly unanswered or
partially answered questions from users.

> There are more ''modern''
> approaches, like Patoline or Sile (of course, based heavily on TeX,
> which is the father of everything). Sile, especially, is very
> interesting and from time to time I like to play with it. The problem
> with these new projects is that they don't have the LaTeX package
> ecosystem, and they are poorly documented. Well, Sile in particular is
> the work of a single person. Links:
>
> https://patoline.github.io/#documentation
>
> https://sile-typesetter.org/

Thanks! This is interesting.

> As for LuaTeX, which is the state of the art today in the TeX ecosystem,
> it is nothing more than TeX + a lua interpreter + the implementation of
> advanced features from previous engines like pdfTeX and the experimental
> Omega/Alef. It has the advantage that it is a scriptable TeX (TeX
> primitives can be controlled by Lua scripts, and truly amazing things[1]
> can be achieved with very little effort[2]); it has the disadvantage that
> the scripting language is Lua. The ideal would have been a Lisp-TeX ;-)
>
> [1] The chickenize package contains many examples, some of them somewhat
> absurd and not very useful in
> appearance: https://www.ctan.org/pkg/chickenize
>
> [2] https://tug.org/TUGboat/tb31-3/tb99isambert.pdf

For me, the main problem with LuaTeX is that it is generally not
supported by publishers I deal with. Mostly, LaTeX is the requirement.
Some even demand Word documents ):

Hence, all the advanced features of LuaTeX cannot be used in real my
real publications and I cannot convince myself to dedicate time for
playing around with LuaTeX.

Do you have anything from LuaTeX in mind that could improve the current
ox-latex pdf export when LuaTeX is used as the TeX engine?

>>> The moment one breaks down a large piece of work into specialized parts,
>>> one gains more control over that piece of work. And org-publish helps
>>> manage all of that. It is about managing a large book as a website (via
>>> org-publish). In short, the combination of org-publish, projectile and
>>> latexmk is quite productive for me in this type of work.
>>
>> This is a bit confusing. You still keep the book in a single giant Org
>> file. It indeed does not mean anything given that we can always narrow
>> to subtree, but I fail to see where you break the book into specialized
>> parts then (LaTeX performance trickery aside).
>
> I think this is inaccurate. The book is split across multiple
> subdocuments. The master file is just the 'outline' of the book.

I see. After watching the video more carefully, I do see the your org
file only had the bibliographies. Not the actual book text.

Best,
Ihor


^ permalink raw reply	[relevance 5%]

* Re: [tip] org-publish to work with (very) large books
  2022-05-29 12:15  5%               ` Ihor Radchenko
@ 2022-05-29 18:01  6%                 ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-29 18:01 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Yet, the information is surprisingly scattered. I was unable to find a
> single guide on the available possibilities. Mostly unanswered or
> partially answered questions from users.

Yes you're right. In addition, what I have been testing is not a panacea
either. In general, when it comes to long and complex documents, there
is no other solution than to arm yourself with patience, launch
asynchronous processes and dedicate yourself to doing another task while
LaTeX does its job. And, of course, trust that there are no errors. The
only advantage to debugging the code of a LaTeX document is how much you
learn about LaTeX and TeX in the process. But many times it is something
that can become frustrating, and the log file can be more cryptic than a
Sumerian inscription. The cause/effect relationship in LaTeX errors can
be the most surrealistic things in the world :-D.

Luckily, there's texstackexchange, where the LaTeX core and LaTeX
package developers themselves write, which is an endless source of
help...

> Do you have anything from LuaTeX in mind that could improve the current
> ox-latex pdf export when LuaTeX is used as the TeX engine?

I've thought about it sometimes, but haven't been able to find anything
concrete for Org. LuaLaTeX cares that a well-formed LaTeX document is
delivered to it, and Org already does that very well. In LuaTeX you can
insert lua code between La(TeX) code. For example:

\begin{luacode}
local x = "foo"
local y = "bar"
tex.print (x .. " and " .. y)
\end{luacode}

But in Org we have all the power of Babel: Org wins.

In LuaTeX you can write functions as pre-process filters, and associate
these functions with different callbacks. For example, there is a
callback_input_buffer, but we already have something like that in Org,
and with a larger scope and not limited to output to LaTeX.

In general, the advanced features of LuaTeX are more typographical and
micro-typographical in nature, and I guess they are of little use to
Org. For example, I recently wrote this function that highlights in red
the text that is in a language other than the main language of the
document (in my case, Spanish, langid 80). Act low-level on the line
node, just before LuaTeX does the line break to create the paragraph:

\directlua{
w = node.new("whatsit","pdf_literal")
w.data = "1 0 0 rg"
z = node.new("whatsit","pdf_literal")
z.data = "0 g"
function other_langs(h,c)
   for n in node.traverse_id(0,h) do
      for x in node.traverse_id(node.id("glyph"),n.head) do
	 if x.lang < 80 or x.lang > 80 then
	    local before, after = node.copy(w), node.copy(z)
	    n.head = node.insert_before(n.head,x,before)
	    n = node.insert_after(n,x,after)
	 end
      end
   end
   return h
   end

luatexbase.add_to_callback('post_linebreak_filter', other_langs, 'other_langs')
}

According to the LuaTeX manual, "TeX’s nodes are represented in Lua as
userdata objects with a variable set of fields". What this function does
is simply manipulate the .lang field of the glyph nodes in an hlist node
(the line with its components).

Functions associated with the post_linebreak_filter callback are very
useful and productive, but from a purely typographical point of view.

At the pure LaTeX level, LuaLaTeX is not very different from LaTeX. Any
LaTeX document, generally speaking, can be compiled with LuaLaTeX, as
long as it is in utf8 and does not contain some pdfLaTeX- or
XelaTeX-specific commands. Today the compatibility between engines is
reasonably good, and more and more packages designed exclusively for
LuaTeX are uploaded to CTAN. The TeX ecosystem is notorious for its
slowness and conformism, but LuaTeX is meant to be the natural
replacement for pdfTeX. Sometime in the uncertain future :-)

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 6%]

* Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
  @ 2022-05-30  5:10  6% ` Ihor Radchenko
  2022-05-30 15:36  9%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-30  5:10 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> I believe that an html attribute to display marginal verse numbers in
> sequence could be useful for certain content, as philological texts
> (like here:
> https://en.wikisource.org/wiki/The_Iliad_and_Odyssey_of_Homer_(Cowper)/Volume_2/The_Odyssey/Book_I)
>
> The `lines' property must be a digit that is equivalent to the verse
> numbers sequence:
>
> #+ATTR_HTML: :lines 5
> #+begin_verse
> some verses...
> #+end_verse

Sounds reasonable. However, a more consistent way to handle line numbers
would be using switches, like what we do in EXAMPLE blocks. See
org-element-example-block-parser and 12.6 Literal Examples section of
the manual.

Similarly, line numbering support can be implemented across more
export backends.

Best,
Ihor


^ permalink raw reply	[relevance 6%]

* Re: # Comments export
  @ 2022-05-30 10:46 10%             ` Juan Manuel Macías
  2022-05-30 21:49  5%               ` Tim Cross
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-30 10:46 UTC (permalink / raw)
  To: Eric S Fraga; +Cc: orgmode

Eric S Fraga writes:

> I use drawers for this and then have specific processing of different
> types of drawers, depending on target.
>
> For instance, I might have :note: drawers (similar to inline tasks) with
> the following processing (for odt export; similar for LaTeX):
>
> --8<---------------cut here---------------start------------->8---
> (setq-local org-odt-format-drawer-function
>             (lambda (name contents)
>               (if (string= name "note")
>                   (progn
>                     (format "<text:span text:background=\"#FFFF00\">%s</text:span>" contents)))))
> --8<---------------cut here---------------end--------------->8---
>
> (progn because I used to do more in there...)

I use a special type of footnote, which is exported to LaTeX as pdf
annotations (with the pdfannotate package) and to odt as comments. The
use of footnotes allows me to put comments and annotations within the
paragraph:

https://list.orgmode.org/877de55cjf.fsf@posteo.net/

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
  2022-05-30  5:10  6% ` Ihor Radchenko
@ 2022-05-30 15:36  9%   ` Juan Manuel Macías
  2022-05-31  5:06  6%     ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-30 15:36 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Sounds reasonable. However, a more consistent way to handle line numbers
> would be using switches, like what we do in EXAMPLE blocks. See
> org-element-example-block-parser and 12.6 Literal Examples section of
> the manual.

(I didn't remember that I had sent this patch...).

I'll take a look at the function you mention, when I have some time. In
any case, keep in mind that there are some conventions in verse
numbering: the white lines (separation between stanzas) are never
numbered and there is a sequence: 5 (first verse alwais remains
unnumbered) ... 10 ... 15 ..., which can be chosen using the :lines
attribute. :lines t defaults to a sequence of 5 verses. I chose this
syntax to follow the syntax of verse numbering with output to LaTeX
(another patch of mine that is already included in Org. In that case,
the 'verse' LaTeX package is used).

Verse numbering is a special case. In fact, a long time ago I wrote this
package: https://gitlab.com/maciaschain/org-verse-num

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: # Comments export
  2022-05-30 10:46 10%             ` Juan Manuel Macías
@ 2022-05-30 21:49  5%               ` Tim Cross
  0 siblings, 0 replies; 200+ results
From: Tim Cross @ 2022-05-30 21:49 UTC (permalink / raw)
  To: emacs-orgmode


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

> Eric S Fraga writes:
>
>> I use drawers for this and then have specific processing of different
>> types of drawers, depending on target.
>>
>> For instance, I might have :note: drawers (similar to inline tasks) with
>> the following processing (for odt export; similar for LaTeX):
>>
>> --8<---------------cut here---------------start------------->8---
>> (setq-local org-odt-format-drawer-function
>>             (lambda (name contents)
>>               (if (string= name "note")
>>                   (progn
>>                     (format "<text:span text:background=\"#FFFF00\">%s</text:span>" contents)))))
>> --8<---------------cut here---------------end--------------->8---
>>
>> (progn because I used to do more in there...)
>
> I use a special type of footnote, which is exported to LaTeX as pdf
> annotations (with the pdfannotate package) and to odt as comments. The
> use of footnotes allows me to put comments and annotations within the
> paragraph:
>
> https://list.orgmode.org/877de55cjf.fsf@posteo.net/
>

I think this is a much better solution. I don't like the idea of adding
the ability to export comments - the whole point of comments are to
provide content which is NOT exported. If you find you have content as
comments which you then want to export, my view would be that these are
not 'comments' in the sense of org-mode. These sound like notes or
annotations and there is likely a better approach than treating them as
org comments. Org comments are probably best thought of as comments
about org content and not org content per se. If you want your comments
to appear as part of yhour exported data at some level, they are no
longer comments, but rather a different class of content and should be
categorised using one of the org content block types or a footnote. 


^ permalink raw reply	[relevance 5%]

* Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
  2022-05-30 15:36  9%   ` Juan Manuel Macías
@ 2022-05-31  5:06  6%     ` Ihor Radchenko
  2022-05-31 11:00  8%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-31  5:06 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> Ihor Radchenko writes:
>
>> Sounds reasonable. However, a more consistent way to handle line numbers
>> would be using switches, like what we do in EXAMPLE blocks. See
>> org-element-example-block-parser and 12.6 Literal Examples section of
>> the manual.
>
> (I didn't remember that I had sent this patch...).
>
> I'll take a look at the function you mention, when I have some time. In
> any case, keep in mind that there are some conventions in verse
> numbering: the white lines (separation between stanzas) are never
> numbered and there is a sequence: 5 (first verse alwais remains
> unnumbered) ... 10 ... 15 ..., which can be chosen using the :lines
> attribute. :lines t defaults to a sequence of 5 verses. I chose this
> syntax to follow the syntax of verse numbering with output to LaTeX
> (another patch of mine that is already included in Org. In that case,
> the 'verse' LaTeX package is used).

The default switches syntax was originally designed for code block and
it generally supports continuous numbering across several subsequent
code blocks or starting the numbering from certain line. Will such
features be useful for verses?

Do you know if customizing :lines 5 to something other than 5 is often
needed? Maybe it can be an export option?

Best,
Ihor


^ permalink raw reply	[relevance 6%]

* Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
  2022-05-31  5:06  6%     ` Ihor Radchenko
@ 2022-05-31 11:00  8%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-31 11:00 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> The default switches syntax was originally designed for code block and
> it generally supports continuous numbering across several subsequent
> code blocks or starting the numbering from certain line. Will such
> features be useful for verses?
> [...]
> Do you know if customizing :lines 5 to something other than 5 is often
> needed? Maybe it can be an export option?

There are some differences between code numbering and verse numbering,
which is a convention used in Humanities and used by wikipedia and other
sites as well:

- The first verse is never numbered;

- White lines are not numbered;

- Numbering is added in a sequence, never continuously. The sequence is
  generally 5, but it is common to find sequences of 3, 10 or other
  digits (with that I answer your second question).

All of these features are performed in LaTeX by the 'verse' package, and
in the patch I submit for LaTeX I simply passed the options to these
package on LaTeX export. See:

(info (org)Verse blocks in LaTeX export)

The :lines attribute accepts any integer for the sequence: :lines 7
:lines 10, etc. :lines t defaults to 5. With this html patch I tried to
keep that same syntax. To format the verse numbering in html I was loosely
inspired by the way wikipedia does it.

I think line numbering is an idiosyncratic case and should not be
confused with standard line numbering as understood by Emacs linum-mode
or any other text editor. What I don't know is if the switches code
numbering could be reused in that peculiar case. An interesting
functionality could be to choose at which number the quoted fragment or
poem begins (because it is common to quote fragments of long poems. In
the LaTeX version this is obtained by :latexcode \setverselinenums{}{}

Nota bene: I understand that all these functionalities for verses are,
at the moment, a minority in Org, since Org has a small number of
Humanities users (here in Spain I try to gain followers among my
colleagues, but it is an arduous task). In any case, I think features
like this can attract more Humanities users...

Best regards,

Juan Manuel 



^ permalink raw reply	[relevance 8%]

* Re: Org-attach for a directory
  @ 2022-06-08 10:32  9% ` Juan Manuel Macías
       [not found]       ` <CAPHku6O3RojzhaSu3d2pWfnE8x7N_9WAfjCupHyKcxNyD-i=ew@mail.gmail.com>
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-08 10:32 UTC (permalink / raw)
  To: Cletip Cletip; +Cc: orgmode

Hi,

Cletip Cletip writes:

> My question is in the object : can we attach a directory to a heading?
> If yes, how, if not, why. Can we solve the problem?

I have in my init the following modification to the org-attach-attach
function so that I can copy a directory. I have replaced the line

((eq method 'cp) (copy-file file attach-file))

with this:

((eq method 'cp) (if (file-directory-p file) 
		     (copy-directory file attach-file)
		   (copy-file file attach-file)))


You can override the old function with advice-add:

(advice-add 'org-attach-attach :override 'my-new-org-attach-attach)

> Subsidiary question:
> Can we use org-attach as a filesystem? 
> Thanks in advance for your future answers

Can you please elaborate more? In my case, I use org-attach almost as a
replacement for my folder system (ie org nodes have come to replace
directories, and many nodes have a folder attached); I access the nodes
via org-ql/helm-org-ql (https://github.com/alphapapa/org-ql). It's very
productive.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: Org-attach for a directory
       [not found]       ` <CAPHku6O3RojzhaSu3d2pWfnE8x7N_9WAfjCupHyKcxNyD-i=ew@mail.gmail.com>
@ 2022-06-09 10:11  8%     ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-09 10:11 UTC (permalink / raw)
  To: Cletip Cletip; +Cc: orgmode

Cletip Cletip writes:

> Thank you for your answer. 

You're welcome.

> Your answer seems perfect to answer my question: I modify a function
> of org-mode, and it allows me to attach folders and files to a
> heading. 
> Unfortunately, it doesn't work (probably because of my version of
> org-mode I guess)
>
> I have the following error:
> make-directory: The file exists:
> /home/user/sharedDirectoryPrivate/notes/braindump/.data/11e080/1b-7896-4f20-a24a-b9f45337e940

I don't know all the details of your problem. But if it gives you an
error saying The file exists, I would say that the cause is that the
directory you want to copy already exists in your attach folder. Could
it be that in your case? Note that the 'copy-directory' function does not
overwrite copied directories.

> Just to make sure I understood correctly: you can, with the "copy"
> method and the simple modification of the "org-attach-attach"
> function, attach a folder to a heading of org mode? 
> If so, this is exactly what I am looking for, and this would be a
> great help.

Exactly. I wrote a new version of org-attach-attach, modified that part,
as I told you, and added it via advice-add (with :override keyword) so
that it overrides the old function.

> To clarify my second question, I would like to have a folder system
> with org-mode, and therefore only use org-attach to arrange my
> documents, exactly like you. 
> Could you describe your workflow in more detail? Your use of tags for
> example, do you put dates, etc.

Now I have less time than I would like to go into the details, but
perhaps some reflections that I shared here may be useful to you:

https://list.orgmode.org/875yms7wys.fsf@posteo.net/

The strong point of my approach is to think of Org nodes and not the
classic directory/file scheme. But for that to work well you must rely
on a system that ensures a semantic search through the nodes. For me the
answer is org-ql (and if you're a helm user, you have helm-org-ql too).
Basically it's turning all your Org documents into a human-readable
database, where searches can be narrowed down by tags, status, content,
etc.

Another important point is that this scheme works wonderfully well with
org-capture.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
@ 2022-06-10 18:28  8% Juan Manuel Macías
  2022-06-11  5:39  6% ` Ihor Radchenko
  2022-06-12 19:18  6% ` Rudolf Adamkovič
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-10 18:28 UTC (permalink / raw)
  To: orgmode

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

Hi,

With this new value, comments are passed to the source file as plain
text, without the org metadata (keywords, property drawers, etc.).

As usual, feedback and suggestions for this patch are greatly appreciated.

Best regards and happy weekend,

Juan Manuel


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ob-tangle.el-add-the-ascii-value-to-the-comment.patch --]
[-- Type: text/x-patch, Size: 2671 bytes --]

From 414e0b3a18abca34bc47f07e55debec0910d4728 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 10 Jun 2022 20:12:37 +0200
Subject: [PATCH] lisp/ob-tangle.el: add the `ascii' value to the `comments'
 head. arg.

* (org-babel-tangle-single-block): With the value ascii the comments
are passed as plain text. This is useful for removing all org
metadata from the source file's comments.
---
 lisp/ob-tangle.el | 53 ++++++++++++++++++++++++++++++++---------------
 1 file changed, 36 insertions(+), 17 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 6685a1599..aed241416 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -525,23 +525,42 @@ non-nil, return the full association list to be used by
 	      (run-hooks 'org-babel-tangle-body-hook)
 	      (buffer-string))))
 	 (comment
-	  (when (or (string= "both" (cdr (assq :comments params)))
-		    (string= "org" (cdr (assq :comments params))))
-	    ;; From the previous heading or code-block end
-	    (funcall
-	     org-babel-process-comment-text
-	     (buffer-substring
-	      (max (condition-case nil
-		       (save-excursion
-			 (org-back-to-heading t) ; Sets match data
-			 (match-end 0))
-		     (error (point-min)))
-		   (save-excursion
-		     (if (re-search-backward
-			  org-babel-src-block-regexp nil t)
-			 (match-end 0)
-		       (point-min))))
-	      (point)))))
+	  (cond ((or (string= "both" (cdr (assq :comments params)))
+		     (string= "org" (cdr (assq :comments params))))
+		 ;; From the previous heading or code-block end
+		 (funcall
+		  org-babel-process-comment-text
+		  (buffer-substring
+		   (max (condition-case nil
+			    (save-excursion
+			      (org-back-to-heading t) ; Sets match data
+			      (match-end 0))
+			  (error (point-min)))
+			(save-excursion
+			  (if (re-search-backward
+			       org-babel-src-block-regexp nil t)
+			      (match-end 0)
+			    (point-min))))
+		   (point))))
+		((string= "ascii" (cdr (assq :comments params)))
+		 ;; From the previous heading or code-block end
+		 (let ((org-babel-process-comment-text
+			(lambda (str)
+			  (org-export-string-as str 'ascii t))))
+		   (funcall
+		    org-babel-process-comment-text
+		    (buffer-substring
+		     (max (condition-case nil
+			      (save-excursion
+				(org-back-to-heading t) ; Sets match data
+				(match-beginning 0))
+			    (error (point-min)))
+			  (save-excursion
+			    (if (re-search-backward
+				 org-babel-src-block-regexp nil t)
+				(match-beginning 0)
+			      (point-min))))
+		     (point)))))))
          (src-tfile (cdr (assq :tangle params)))
 	 (result
 	  (list start-line
-- 
2.36.1


^ permalink raw reply related	[relevance 8%]

* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
  2022-06-10 18:28  8% [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments' Juan Manuel Macías
@ 2022-06-11  5:39  6% ` Ihor Radchenko
  2022-06-11 11:20  9%   ` Juan Manuel Macías
  2022-06-12 19:18  6% ` Rudolf Adamkovič
  1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-06-11  5:39 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> With this new value, comments are passed to the source file as plain
> text, without the org metadata (keywords, property drawers, etc.).
>
> As usual, feedback and suggestions for this patch are greatly appreciated.
>
> Best regards and happy weekend,

Thanks for the patch!
Wouldn't it be better to supply a customization for
org-babel-process-comment-text instead?

I do not feel that per-src-block control on the comment type makes much
sense here.

Best,
Ihor


^ permalink raw reply	[relevance 6%]

* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
  2022-06-11  5:39  6% ` Ihor Radchenko
@ 2022-06-11 11:20  9%   ` Juan Manuel Macías
  2022-06-14  3:58  6%     ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-11 11:20 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Hi, Ihor, thanks for your comments,

Ihor Radchenko writes:

> Wouldn't it be better to supply a customization for
> org-babel-process-comment-text instead?
>
> I do not feel that per-src-block control on the comment type makes much
> sense here.

My first approach was actually to define some options for
org-babel-process-comment. But I noticed that a header with properties,
for example:

* Header
  :PROPERTIES:
  :FOO:      var
  :END:

is interpreted as:

;; Header
;; :FOO: var

I think the culprit is the '(match-end 0)' in
org-babel-tangle-single-block:

...
(comment
	  (when (or (string= "both" (cdr (assq :comments params)))
		    (string= "org" (cdr (assq :comments params))))
	    ;; From the previous heading or code-block end
	    (funcall
	     org-babel-process-comment-text
	     (buffer-substring
	      (max (condition-case nil
		       (save-excursion
			 (org-back-to-heading t) ; Sets match data
			 (match-end 0)) ;; <=========
		     (error (point-min)))
		   (save-excursion
		     (if (re-search-backward
			  org-babel-src-block-regexp nil t)
			 (match-end 0)  ;; <=========
		       (point-min))))
	      (point)))))
...

So I couldn't think of any other solution than to put the change there,
so as not to break backwards compatibility. But it is a somewhat tricky
solution...

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
  2022-06-10 18:28  8% [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments' Juan Manuel Macías
  2022-06-11  5:39  6% ` Ihor Radchenko
@ 2022-06-12 19:18  6% ` Rudolf Adamkovič
  2022-06-12 19:55  9%   ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Rudolf Adamkovič @ 2022-06-12 19:18 UTC (permalink / raw)
  To: Juan Manuel Macías, orgmode

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

> As usual, feedback and suggestions for this patch are greatly
> appreciated.

Juan, hi!

I do not understand the meaning of ASCII.  How will such comments look
like?  Will they include at least the file name?  If so, those can
contain Unicode characters, right?

Rudy
-- 
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia


^ permalink raw reply	[relevance 6%]

* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
  2022-06-12 19:18  6% ` Rudolf Adamkovič
@ 2022-06-12 19:55  9%   ` Juan Manuel Macías
  2022-06-13  8:24  6%     ` Rudolf Adamkovič
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-12 19:55 UTC (permalink / raw)
  To: Rudolf Adamkovič; +Cc: orgmode

Hi, Rudolph, thanks for your comments,

Rudolf Adamkovič writes:

> Juan, hi!
>
> I do not understand the meaning of ASCII.  How will such comments look
> like?  Will they include at least the file name?  If so, those can
> contain Unicode characters, right?

The main motivation for proposing this new option is that when I choose
the ':comments org' option, all the Org metadata that is close to the
code block in my org file are 'preserved', so comments in the source
file are somewhat awkward to read (as simple comments). My idea is that
with this new option the comments pass as plain text, without property
drawers, keywords, etc.

For example, that a header like this:

------------------------------------
* Variables
  :PROPERTIES:
  :foo:      var
  :END:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
hendrerit tempor tellus. Donec pretium posuere tellus.
------------------------------------

does not pass to the source file like this:

------------------------------------
;; Variables
;;   :PROPERTIES:
;;   :foo:      var
;;   :END:
;; Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
;; hendrerit tempor tellus. Donec pretium posuere tellus.
------------------------------------

but in this way:

------------------------------------
;; Variables
;; ==========
;; Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
;; hendrerit tempor tellus. Donec pretium posuere tellus.
------------------------------------

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 9%]

* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
  2022-06-12 19:55  9%   ` Juan Manuel Macías
@ 2022-06-13  8:24  6%     ` Rudolf Adamkovič
  2022-06-13 10:22 10%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Rudolf Adamkovič @ 2022-06-13  8:24 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> but in this way:
>
> ------------------------------------
> ;; Variables
> ;; ==========
> ;; Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
> ;; hendrerit tempor tellus. Donec pretium posuere tellus.
> ------------------------------------

Hello again, Juan!

Oh, I see.  Thank you for the explanation.  I can see myself using such
new tangle comments all the time!  But then, I use UTF-8 and not the
standard 7-bit ASCII for my Org documents.  Hence, I would want to see
':comments plain' or ':comments plain-text' instead.

Rudy
-- 
"Genius is 1% inspiration and 99% perspiration."
-- Thomas Alva Edison, 1932

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia


^ permalink raw reply	[relevance 6%]

* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
  2022-06-13  8:24  6%     ` Rudolf Adamkovič
@ 2022-06-13 10:22 10%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-13 10:22 UTC (permalink / raw)
  To: Rudolf Adamkovič; +Cc: orgmode

Hi, Rudolph,

Rudolf Adamkovič writes:

> Oh, I see.  Thank you for the explanation.  I can see myself using such
> new tangle comments all the time!  But then, I use UTF-8 and not the
> standard 7-bit ASCII for my Org documents.  Hence, I would want to see
> ':comments plain' or ':comments plain-text' instead.

What you comment makes sense, because `ascii' can lead to confusion. I
chose the term `ascii' because the backend used to convert the text is
called `ascii', although if I evaluate something like

(org-export-string-as "αβγδ" 'ascii t)

the result is utf8.

I think it might be a good idea to use `plain' for the value name, as
you say, instead of `ascii'...

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
  2022-06-11 11:20  9%   ` Juan Manuel Macías
@ 2022-06-14  3:58  6%     ` Ihor Radchenko
  2022-06-14 11:11  8%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-06-14  3:58 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> My first approach was actually to define some options for
> org-babel-process-comment. But I noticed that a header with properties,
> for example:
> ...
>
> I think the culprit is the '(match-end 0)' in
> org-babel-tangle-single-block:
>
> ...
> 			 (org-back-to-heading t) ; Sets match data
> 			 (match-end 0)) ;; <=========
> 		     (error (point-min)))

I think that the existing code can be improved. Relying on the
undocumented behavior of (org-back-to-heading) is not ideal. Not to
mention code blocks before first headline.

It would be great if you rewrite the existing code to suite both the
defaults and the proposed behavior.

Best,
Ihor


^ permalink raw reply	[relevance 6%]

* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
  2022-06-14  3:58  6%     ` Ihor Radchenko
@ 2022-06-14 11:11  8%       ` Juan Manuel Macías
  2022-06-14 11:55  6%         ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-14 11:11 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> I think that the existing code can be improved. Relying on the
> undocumented behavior of (org-back-to-heading) is not ideal. Not to
> mention code blocks before first headline.
>
> It would be great if you rewrite the existing code to suite both the
> defaults and the proposed behavior.

Yes, I agree that this needs a more robust approach. Also, I've noticed
that the patch I've proposed has a rather silly bug: replacing the
second `match-end 0' with `match-beginning 0' naturally causes
intermediate code blocks to be exported as comments (!). Returning it to
`match-end 0' everything is OK, but the present approach is still
tricky.

I'm going to see if I can try something cleaner these days. Ideally,
everything should be controlled from org-babel-process-comment-text...

On the other hand, I have a curiosity. I understand that the behavior of
the `:comments org' option should be left intact to ensure backwards
compatibility. But I've always wondered if there is any use case where
this value, as it behaves, might be practical. I don't quite understand
how useful all the Org metadata in the comments of the tangled file can
be. The expectation with `:comments org' is that only the content of the
Org document will be rendered (as comments), but not its metadata, that
all they do is unnecessarily fatten up the source file. I'm thinking,
for example, of headers with lots of properties. or comment blocks,
which would be visible in the tangled source file:

┌────
│ ;;   Header
│ ;;   :PROPERTIES:
│ ;;   :A_LOT_OF: properties
│ ;;   :END:
│ 
│ ;; #+begin_comment
│ ;; Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus.
│ ;; Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec,
│ ;; purus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus
│ ;; mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. Cras placerat
│ ;; accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl.
│ ;; #+end_comment
└────

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
  2022-06-14 11:11  8%       ` Juan Manuel Macías
@ 2022-06-14 11:55  6%         ` Ihor Radchenko
  2022-06-15 10:30  9%           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-06-14 11:55 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> On the other hand, I have a curiosity. I understand that the behavior of
> the `:comments org' option should be left intact to ensure backwards
> compatibility. But I've always wondered if there is any use case where
> this value, as it behaves, might be practical. I don't quite understand
> how useful all the Org metadata in the comments of the tangled file can
> be. The expectation with `:comments org' is that only the content of the
> Org document will be rendered (as comments), but not its metadata, that
> all they do is unnecessarily fatten up the source file. I'm thinking,
> for example, of headers with lots of properties. or comment blocks,
> which would be visible in the tangled source file:

The original proposal by Eric Schulte:
https://list.orgmode.org/4BFFEE4F.5010608@ccbr.umn.edu/
>>> Maybe we should allow either exporting just the headlines of the
>>> org-mode file or exporting the entire org-mode file -- possibly after an
>>> ASCII export -- this would have the effect of prefixing every line in
>>> the org-mode file behind a comment *except* for the tangled source-code
>>> blocks.

Clearly, the "possible after an ASCII export" dropped somewhere in the
middle.

Best,
Ihor


^ permalink raw reply	[relevance 6%]

* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
  2022-06-14 11:55  6%         ` Ihor Radchenko
@ 2022-06-15 10:30  9%           ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-15 10:30 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> The original proposal by Eric Schulte:
> https://list.orgmode.org/4BFFEE4F.5010608@ccbr.umn.edu/
>>>> Maybe we should allow either exporting just the headlines of the
>>>> org-mode file or exporting the entire org-mode file -- possibly after an
>>>> ASCII export -- this would have the effect of prefixing every line in
>>>> the org-mode file behind a comment *except* for the tangled source-code
>>>> blocks.
>
> Clearly, the "possible after an ASCII export" dropped somewhere in the
> middle.

I see... Thanks for the clarification! So it seems that the current
behavior of ':comments org' is no more than a fluke, rather than
intentional. One possibility that occurs to me, instead of adding a new
value to ':comments', would be to 'return' ASCII export for the
:comments org value, and leave it that way by default. And add an
option, of course, for recover the old value. It could be done from
org-babel-process-comment-text, and then redo some lines in
org-babel-tangle-single-block, as we discussed in the other mail. I
think it would be cleaner that way, but I don't know if this would be
too groundbreaking...

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: Utility of description lists
  @ 2022-06-17 14:24  9% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-17 14:24 UTC (permalink / raw)
  To: Cletip Cletip; +Cc: orgmode

Hi,

Cletip Cletip writes:

> - they are made implicitly to make a "key :: value" couple, which can
> be convenient

Leaving aside typographical considerations, what LaTeX calls, for
example, "description" (because Org is totally typographic agnostic), I
find this property that you mention very useful. For example, for my
translation (work in progress) of Homer's Odyssey, I am writing a
descriptive list with the Homeric formulas in Greek (key) and how I
translate each specific formula (value), since they are terms that are
repeated a lot in the text. With a bit of Elisp I can later recover
some specific formula from the list.

See: https://list.orgmode.org/87bl5tzof2.fsf@posteo.net/

Then, when I publish the translation (if I ever finish it ;-)), that
list will be translated in typographic terms, into a glossary of
homeric formulas.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: About 'inline special blocks'
  @ 2022-06-17 19:49 10%           ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-17 19:49 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko <yantar92@gmail.com> writes:

> While arbitrary markup can indeed be introduced using our current link
> syntax, there is one important limitation of links:
>
>  *** link description cannot contain other links ***
>
> If one seriously tries to extend Org syntax with custom markup elements,
> nested markup will not be possible. And we do not want to change Org
> links to allow other links inside.
>
> Inline special blocks may not have such limitation if we allow special
> blocks to be nested.

  +1.

This seems to me a *very* important point.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* [Tip] Screenshots as org links with EMMS and socat
@ 2022-06-18 14:35  7% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-18 14:35 UTC (permalink / raw)
  To: orgmode

Hi all,

I’m writing an article about a movie, and I needed to get some
screenshots as image links inside Org. I know some package for those
things, like org-media-note, a nice library but for me it has two
drawbacks: it has, for what I need, too many bells and whistles; and
uses the mpv.el package in the background. I use the mpv player, but
through EMMS. In fact, I have all my multimedia setup in Emacs around
EMMS, and I'm too lazy to use something else. What I am looking for is,
therefore, something much simpler, EMMS-centric and "homemade". If
someone is in the same situation as me and also uses EMMS with mpv, I’m
sharing my solution here, in case it’s useful (I’ve taken some ideas
from org-media-note and mpv.el):

Socat needs to be installed first, to communicate with the mpv process
via the command line. In Arch it is in the official repositories:

┌────
│ sudo pacman -S socat
└────

My EMMS configuration:

┌────
│ (require 'emms-setup)
│ (emms-all)
│ (emms-default-players)
│ (setq emms-player-list '(emms-player-mpv))
└────

And these two variables are for socat communication:

┌────
│ (setq emms-player-mpv-ipc-method 'ipc-server)
│ (setq emms-player-mpv-ipc-socket "~/.emacs.d/emms/mpv-ipc.sock")
└────

The directory to save the screenshots:

┌────
│ (defvar my-screenshot-dir "/path/to/screenshot/dir/")
└────

This function returns the formatted timestamp and path of the current
mpv process:

┌────
│ (require 'org-timer)
│ (defun my-mpv-format-timestamp-and-path ()
│   (let* ((timestamp-command (shell-command-to-string
│ 	  "echo '{ \"command\": [\"get_property\", \"playback-time\"] }' | socat - ~/.emacs.d/emms/mpv-ipc.sock"))
│ 	 (path-command (shell-command-to-string
│ 	"echo '{ \"command\": [\"get_property\", \"path\"] }' | socat - ~/.emacs.d/emms/mpv-ipc.sock"))
│ 	 (timestamp (org-timer-secs-to-hms (round
│ 					    (cdr
│ 					     (car
│ 					      (json-read-from-string timestamp-command))))))
│ 	 (path (cdr
│ 		(car
│ 		 (json-read-from-string path-command)))))
│     (format "%s --- %s" path timestamp)))
└────

And, finally, the function that inserts the screenshot at point as an
org image link:

┌────
│ (defun my-mpv-put-screenshot-on-org ()
│   (let* ((time (format-time-string "%d-%m-%y-%H-%M-%S"))
│ 	 (screenshot-file-name (format "fotograma-%s.png" time))
│ 	 (screenshot-final (expand-file-name screenshot-file-name my-screenshot-dir)))
│     (start-process-shell-command 
│      "screenshot" nil
│      (format
│       "echo \"screenshot-to-file %s\" | socat - \"~/.emacs.d/emms/mpv-ipc.sock\""
│       screenshot-final))
│     (insert (format "#+media: %s\n" (my-mpv-format-timestamp-and-path)))
│     (insert (format "[[file:%s]]" screenshot-final))))
└────

A short demo video: https://cloud.disroot.org/s/6zrGYxkKT67kFGx

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 7%]

* Re: About 'inline special blocks'
  2022-05-23 15:20  4% ` Kaushal Modi
  2022-05-23 21:06  9%   ` Juan Manuel Macías
@ 2022-06-19 12:47  7%   ` Juan Manuel Macías
  2022-06-19 19:30  5%     ` Christian Moe
  2022-06-19 22:18  5%     ` Tim Cross
  1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-19 12:47 UTC (permalink / raw)
  To: orgmode

To add some ideas that have been occurring to me these days...

I am more and more convinced that inline special blocks, by their
nature, should not support fine tune options or anything like
attr_latex, attr_html, etc. like its older brothers, as it would produce
an overly complicated syntax. Big brothers are independent of the
paragraph and there it makes sense to add lines with attr_latex, etc.,
since it is a line-oriented syntax. Bringing that into the paragraph is
unnecessarily overloading the paragraph and breaking the social contract
of lightweight markup, where paragraphs should still look like
paragraphs.

Another argument against possible fine-tuning within inline special
blocks, for export purposes, is that (in my opinion) direct formatting
is a practice that should be avoided as much as possible in a document.
A document with a lot of direct formatting is an inconsistent document.
In html, all possible formatting should be controlled by style sheets;
in LaTeX, by (re)defining macros, commands and environments in the
preamble or in a .sty file; in odt using character styles.

Perhaps if we detach special blocks from fine-tuning possibilities we
lose some (export) flexibility, but we gain in a clearer implementation
of these elements and keep Org aseptic about the output format. And in
any case, if someone needs a fine-tuning in a certain case, there are
always the export filters. Or it can be implemented in a similar way to
inline tasks, with a default format function (for html, latex, etc),
which can be changed via a defcustom.

Starting from that, a syntax like this in Org:

%[name]{contents}

Would produce in LaTeX, by default:

\name{contents}

in html:

<name>contents></name>

in odt:

<text:span text:style-name="name">contents</text:span>

and so on.

In short, I think it would be enough to simply implement something like
this.

Best regards,

Juan Manuel 



^ permalink raw reply	[relevance 7%]

* Re: Keybinding doubt about ARG
  @ 2022-06-19 17:21 10%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-19 17:21 UTC (permalink / raw)
  To: Bruno Barbier; +Cc: orgmode

Bruno Barbier writes:

> But, you can easily define your own command.
>
>     (defun my-scroll-up-of-1 ()
>       (interactive)
>       (scroll-up-command 1))
>
>     (define-key global-map (kbd "M-n") 'my-scroll-up-of-1)

Or simply doing something like:

(define-key global-map (kbd "M-n") (lambda ()
                                     (interactive)
                                     (scroll-up-command 1)))

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 10%]

* Re: About 'inline special blocks'
  2022-06-19 12:47  7%   ` Juan Manuel Macías
@ 2022-06-19 19:30  5%     ` Christian Moe
  2022-06-19 20:15  9%       ` Juan Manuel Macías
  2022-06-19 22:18  5%     ` Tim Cross
  1 sibling, 1 reply; 200+ results
From: Christian Moe @ 2022-06-19 19:30 UTC (permalink / raw)
  To: emacs-orgmode


Juan Manuel Macías writes:

> To add some ideas that have been occurring to me these days...
>

Hi,

This makes sense to me.

Note: For the html output in your example, I expect you don't mean
<name>contents></name>, but <span class="name">contents</span>. That
would give the desired custom style controle of the output, and would
parallel the behavior of special blocks.

If "inline special blocks" will be able to nest, they will have an
advantage over org macros, which cannot.

Apart from nesting, an org macro could do the same job, but less
elegantly. The suggested inline syntax would not require commas to be
escaped in the contents. And it would be somewhat more concise and far
more legible, as illustrated in the below example (with working macros,
imagined inline special blocks, and a CSS implementation):

#+begin_example
#+macro: fmt @@html:<span class="$1">$2</span>@@@@latex:\$1{$2}@@@@odt:<text:span text:style-name="$1">$2</text:span>@@
#+html_head: <style>.highlight {background-color: yellow;}
#+html_head:        .smallcaps {font-variant: small-caps;}</style>

This is some {{{fmt(highlight, highlighted text)}}} and this is some
{{{fmt(smallcaps, text in small caps)}}}.

This is some %[highlight]{highlighted text} and this is some
%[smallcaps]{text in small caps}.
#+end_example

Yours,
Christian

> I am more and more convinced that inline special blocks, by their
> nature, should not support fine tune options or anything like
> attr_latex, attr_html, etc. like its older brothers, as it would produce
> an overly complicated syntax. Big brothers are independent of the
> paragraph and there it makes sense to add lines with attr_latex, etc.,
> since it is a line-oriented syntax. Bringing that into the paragraph is
> unnecessarily overloading the paragraph and breaking the social contract
> of lightweight markup, where paragraphs should still look like
> paragraphs.
>
> Another argument against possible fine-tuning within inline special
> blocks, for export purposes, is that (in my opinion) direct formatting
> is a practice that should be avoided as much as possible in a document.
> A document with a lot of direct formatting is an inconsistent document.
> In html, all possible formatting should be controlled by style sheets;
> in LaTeX, by (re)defining macros, commands and environments in the
> preamble or in a .sty file; in odt using character styles.
>
> Perhaps if we detach special blocks from fine-tuning possibilities we
> lose some (export) flexibility, but we gain in a clearer implementation
> of these elements and keep Org aseptic about the output format. And in
> any case, if someone needs a fine-tuning in a certain case, there are
> always the export filters. Or it can be implemented in a similar way to
> inline tasks, with a default format function (for html, latex, etc),
> which can be changed via a defcustom.
>
> Starting from that, a syntax like this in Org:
>
> %[name]{contents}
>
> Would produce in LaTeX, by default:
>
> \name{contents}
>
> in html:
>
> <name>contents></name>
>
> in odt:
>
> <text:span text:style-name="name">contents</text:span>
>
> and so on.
>
> In short, I think it would be enough to simply implement something like
> this.
>
> Best regards,
>
> Juan Manuel


^ permalink raw reply	[relevance 5%]

* Re: About 'inline special blocks'
  2022-06-19 19:30  5%     ` Christian Moe
@ 2022-06-19 20:15  9%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-19 20:15 UTC (permalink / raw)
  To: Christian Moe; +Cc: orgmode

Hi, Christian,

Thanks for your comments.

Christian Moe writes:

> Hi,
>
> This makes sense to me.
>
> Note: For the html output in your example, I expect you don't mean
> <name>contents></name>, but <span class="name">contents</span>. That
> would give the desired custom style controle of the output, and would
> parallel the behavior of special blocks.

You are absolutely right, it is my fault. These days I'm doing a work
with a lot of xml, and I've mixed things up in my head :-). In html the
expected form is as you say. Apologize for the confusion.

> If "inline special blocks" will be able to nest, they will have an
> advantage over org macros, which cannot.
>
> Apart from nesting, an org macro could do the same job, but less
> elegantly. The suggested inline syntax would not require commas to be
> escaped in the contents. And it would be somewhat more concise and far
> more legible, as illustrated in the below example (with working macros,
> imagined inline special blocks, and a CSS implementation):
>
> #+begin_example
> #+macro: fmt @@html:<span class="$1">$2</span>@@@@latex:\$1{$2}@@@@odt:<text:span text:style-name="$1">$2</text:span>@@
> #+html_head: <style>.highlight {background-color: yellow;}
> #+html_head:        .smallcaps {font-variant: small-caps;}</style>
>
> This is some {{{fmt(highlight, highlighted text)}}} and this is some
> {{{fmt(smallcaps, text in small caps)}}}.
>
> This is some %[highlight]{highlighted text} and this is some
> %[smallcaps]{text in small caps}.
> #+end_example

I have used macros a lot in the past for these purposes. But the problem
of having to escape commas and the somewhat confusing (and ugly) syntax
of macros has led me to rarely use them now. Links have been a good
replacement for me, but they still have their limitations (the most
important, as Ihor commented, not being able to include a link within
the description. But we can't put footnotes either). I actually think
that inline special blocks could be tremendously useful and versatile.
And, in syntactic terms, an important point in favor of Org against
Markdown, which if I'm not mistaken does not have anything similar (I
hardly use md, so I'm not very aware).

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 9%]

* Re: About 'inline special blocks'
  2022-06-19 12:47  7%   ` Juan Manuel Macías
  2022-06-19 19:30  5%     ` Christian Moe
@ 2022-06-19 22:18  5%     ` Tim Cross
  1 sibling, 0 replies; 200+ results
From: Tim Cross @ 2022-06-19 22:18 UTC (permalink / raw)
  To: emacs-orgmode


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

> To add some ideas that have been occurring to me these days...
>
> I am more and more convinced that inline special blocks, by their
> nature, should not support fine tune options or anything like
> attr_latex, attr_html, etc. like its older brothers, as it would produce
> an overly complicated syntax. Big brothers are independent of the
> paragraph and there it makes sense to add lines with attr_latex, etc.,
> since it is a line-oriented syntax. Bringing that into the paragraph is
> unnecessarily overloading the paragraph and breaking the social contract
> of lightweight markup, where paragraphs should still look like
> paragraphs.
>

Agree. I think your reasoning here is spot on. 

> Another argument against possible fine-tuning within inline special
> blocks, for export purposes, is that (in my opinion) direct formatting
> is a practice that should be avoided as much as possible in a document.
> A document with a lot of direct formatting is an inconsistent document.
> In html, all possible formatting should be controlled by style sheets;
> in LaTeX, by (re)defining macros, commands and environments in the
> preamble or in a .sty file; in odt using character styles.
>

Agreed. In fact, I use in-line blocks so rarely that at first I wasn't
going to respond as I really didn't have much skin in the game when it
comes to inline blocks. The reason I dond't use them much is pretty much
the same as your reasoning above.

> Perhaps if we detach special blocks from fine-tuning possibilities we
> lose some (export) flexibility, but we gain in a clearer implementation
> of these elements and keep Org aseptic about the output format. And in
> any case, if someone needs a fine-tuning in a certain case, there are
> always the export filters. Or it can be implemented in a similar way to
> inline tasks, with a default format function (for html, latex, etc),
> which can be changed via a defcustom.
>

I also like this approach. We need some form of escape hatch. However,
for uncommon edge cases, I would rather have a slightly less convenient
escape hatch and a simple consistent general syntax than a more complex
syntax which is difficult to maintain and keep consistent and reliable. 

> Starting from that, a syntax like this in Org:
>
> %[name]{contents}
>
> Would produce in LaTeX, by default:
>
> \name{contents}
>
> in html:
>
> <name>contents></name>

or should that be <span class="name">contents</name>?


>
> in odt:
>
> <text:span text:style-name="name">contents</text:span>
>
> and so on.
>
> In short, I think it would be enough to simply implement something like
> this.
>

Sound reasoning IMO. 


^ permalink raw reply	[relevance 5%]

Results 601-800 of ~1600   |  | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2014-03-04 13:11     [RFC] Creole-style / Support for **emphasis**__within__**a word** Jambunathan K
2014-03-22 14:05     ` Nicolas Goaziou
2014-03-23  2:59       ` Jambunathan K
2022-01-24 10:50         ` [O] " Vincent Belaïche
2022-01-24 12:09  9%       ` Juan Manuel Macías
2022-01-24 12:32  6%         ` Vincent Belaïche
2022-01-25 10:55               ` Nicolas Goaziou
2022-01-25 17:18  3%             ` Vincent Belaïche
2022-01-25 17:30  9%               ` Juan Manuel Macías
2022-01-25 18:45  6%                 ` Vincent Belaïche
2022-01-25 18:20  5%               ` Vincent Belaïche
2021-10-04 14:27     [patch] ox-html.el: add html attribute (verse numbers) to verse blocks Juan Manuel Macías
2022-05-30  5:10  6% ` Ihor Radchenko
2022-05-30 15:36  9%   ` Juan Manuel Macías
2022-05-31  5:06  6%     ` Ihor Radchenko
2022-05-31 11:00  8%       ` Juan Manuel Macías
2021-12-02 10:50     Org-syntax: Intra-word markup Denis Maier
2021-12-02 11:58     ` Timothy
2021-12-02 12:26       ` Denis Maier
2021-12-02 13:07         ` Ihor Radchenko
2021-12-02 19:03           ` Nicolas Goaziou
2021-12-03 14:24             ` Max Nikulin
2021-12-04 15:57               ` Denis Maier
2021-12-04 17:53                 ` Tom Gillespie
2021-12-04 19:04                   ` Timothy
2021-12-04 21:48                     ` Tom Gillespie
2022-01-28 14:52                       ` Max Nikulin
2022-01-29  3:13                         ` Ihor Radchenko
2022-01-29 13:05  9%                       ` Juan Manuel Macías
2022-02-02 15:28  5%                         ` Max Nikulin
2022-02-02 20:01  9%                           ` Juan Manuel Macías
2022-02-03 12:10  4%                             ` Max Nikulin
2022-01-28 12:12     ` [PATCH] Intra-word markup: \relax Max Nikulin
2022-01-28 13:13  9%   ` Juan Manuel Macías
2022-02-02 15:42  5%     ` Max Nikulin
2022-01-17 14:14     latex block tikz to svg Edouard Debry
2022-01-17 16:01     ` Juan Manuel Macías
2022-01-25 23:24  6%   ` Edouard Debry
2022-04-18 13:23  4%   ` Edouard Debry
2022-01-20 14:33     Exporting Org file to Html with collapsable headings ZIPING CHEN
2022-01-21 12:23     ` Juan Manuel Macías
2022-01-21 16:46       ` Max Nikulin
2022-01-22 18:20  0%     ` xincheng99
2022-01-24 15:59     Missing the second '}' Sharon Kimble
2022-01-24 16:46  9% ` Juan Manuel Macías
2022-01-28 17:41     date format in agenda view Uwe Brauer
2022-01-28 17:57 10% ` Juan Manuel Macías
2022-01-28 18:05  0%   ` Uwe Brauer
2022-01-30 12:32  9% A callygraphy notebook environment Juan Manuel Macías
2022-01-30 20:37  1% ` Uwe Brauer
2022-01-30 21:23  9%   ` Juan Manuel Macías
2022-01-31 13:55  0%     ` Uwe Brauer
2022-02-11 20:37  8% [PATCH] org-manual.org: update and add info for arbitrary :float values Juan Manuel Macías
2022-02-13 21:18  6% ` Nicolas Goaziou
2022-02-13 22:21 10%   ` Juan Manuel Macías
2022-02-15 13:24  6%     ` Nicolas Goaziou
2022-02-16 19:52  8%       ` [PATCH] ox-latex.el: Add a `t' value for `:float' in tables and figures (was: update and add info for arbitrary :float values) Juan Manuel Macías
2022-02-22 19:14  6%         ` [PATCH] ox-latex.el: Add a `t' value for `:float' in tables and figures Nicolas Goaziou
2022-02-12 20:12     Bug with exporting list with link item containing "::" to markdown Cash Weaver
2022-02-23 16:59  5% ` Max Nikulin
2022-02-15 10:23     Root heading when exporting sub-trees Michael Dauer
2022-02-15 12:36 10% ` Juan Manuel Macías
2022-02-15 20:48     table format during html export Leo Butler
2022-02-15 22:16 10% ` Juan Manuel Macías
2022-02-16 15:57  6%   ` Leo Butler
2022-02-17 14:56     Question Regarding Creating HTML Style Buttons With Org Mode Samuel Banya
2022-02-17 22:10 10% ` Juan Manuel Macías
2022-02-18 19:59  6%   ` Samuel Banya
2022-02-18 20:04  0%     ` Samuel Banya
2022-02-18 20:38 10%     ` Juan Manuel Macías
2022-02-18 20:51 12%       ` Juan Manuel Macías
2022-02-19  1:02  6%         ` Samuel Banya
2022-02-19  9:41  8%           ` Juan Manuel Macías
2022-02-19  9:51 12%             ` Juan Manuel Macías
2022-02-21  0:38  6%               ` Samuel Banya
2022-02-23  2:25  1%                 ` Samuel Banya
2022-02-23  2:33 10%                   ` Juan Manuel Macías
2022-02-18  0:47  8% Pandoc and nested emhases Juan Manuel Macías
2022-02-18 12:06  4% ` Max Nikulin
2022-02-18 12:31 10%   ` Juan Manuel Macías
2022-02-24 12:50  5%     ` Max Nikulin
2022-02-22  4:32  9% Footnote tooltips (an attempt) Juan Manuel Macías
2022-02-22 22:15 11% ` Juan Manuel Macías
2022-02-22 16:04  8% Open a footnote definition outside a narrowed subtree (workaround) Juan Manuel Macías
2022-02-22 16:45  6% ` Nicolas Goaziou
2022-02-22 17:34 10%   ` Juan Manuel Macías
     [not found]     <mailman.57.1645549224.6185.emacs-orgmode@gnu.org>
2022-02-22 22:30     ` Footnote tooltips (an attempt) Ypo
2022-02-23  2:26  9%   ` Juan Manuel Macías
     [not found]         ` <CAJcAo8tsK5o+789Wv=i6ddiSrM4fDyX8HCvjAgDLXGyLXWRWmQ@mail.gmail.com>
2022-02-23 19:52  9%       ` Juan Manuel Macías
2022-02-23 22:05  4%         ` John Kitchin
2022-02-24  2:04  8%           ` Juan Manuel Macías
2022-02-24 13:01  6%             ` John Kitchin
2022-02-24 16:25 10%               ` Juan Manuel Macías
2022-02-24 19:12     ConTeXt exporter makes me happy juh
2022-02-24 19:58  9% ` Juan Manuel Macías
2022-02-26 14:33     including one double quote in an anonymous footnote? Greg Minshall
2022-02-26 14:47 10% ` Juan Manuel Macías
2022-02-26 15:00       ` Greg Minshall
2022-02-26 19:20  9%     ` Juan Manuel Macías
2022-02-28 14:47  6%       ` Nicolas Goaziou
2022-02-28 18:36             ` Greg Minshall
2022-02-28 20:57 10%           ` Juan Manuel Macías
2022-03-05 15:40     Filter for HTML footnotes? M. ‘quintus’ Gülker
2022-03-06  4:03  9% ` Juan Manuel Macías
2022-03-08  7:40  5%   ` Filter for HTML (cite) footnotes? M. ‘quintus’ Gülker
2022-03-08 10:14 10%     ` Juan Manuel Macías
2022-03-05 19:58  9% Move or rename a file in a link Juan Manuel Macías
2022-03-06  8:09  3% ` Uwe Brauer
2022-03-09 20:30  6% ` João Pedro de Amorim Paula
2022-03-10 14:58 10%   ` Juan Manuel Macías
2022-03-18 18:52  6%     ` João Pedro de Amorim Paula
2022-03-19 11:25  8%       ` Juan Manuel Macías
2022-03-22 15:30  5%         ` João Pedro de Amorim Paula
2022-03-07 15:18     interleaving comment between rows of a table? Greg Minshall
2022-03-07 15:54 10% ` Juan Manuel Macías
2022-03-11 22:24 10% helm-org-names: browse the names of code blocks, tables and figures Juan Manuel Macías
2022-03-13 10:54     Code blocks and quotes export style Sébastien Gendre
2022-03-13 16:06     ` Kaushal Modi
2022-03-13 18:39  7%   ` Juan Manuel Macías
2022-03-14 12:50  6%     ` Max Nikulin
2022-03-14 18:09 10%       ` Juan Manuel Macías
2022-03-15  3:28     LaTeX export of a file with some accented characters Vikas Rawal
2022-03-15 20:23 10% ` Juan Manuel Macías
2022-03-16 11:23     leading superscript on a line for ODT export Eric S Fraga
2022-03-16 12:03 10% ` Juan Manuel Macías
2022-03-16 12:46  6%   ` Eric S Fraga
2022-03-16 13:12 10%     ` Juan Manuel Macías
2022-03-16 13:42  6%       ` Eric S Fraga
2022-03-16 13:46     ` Max Nikulin
2022-03-16 14:07 10%   ` Juan Manuel Macías
2022-03-17 22:44  7% Org and multimedia (tips?) Juan Manuel Macías
2022-03-18 14:40  6% ` Max Nikulin
2022-03-19 11:13 10%   ` Juan Manuel Macías
2022-05-05  1:14  5% ` TRS-80
2022-04-01 23:22     TOC and latex memoir class Steve Downey
2022-04-02  7:21 10% ` Juan Manuel Macías
2022-04-03  9:18     when exporting latex how to set with in the includegraphics command Uwe Brauer
2022-04-03 10:19 10% ` Juan Manuel Macías
2022-04-03 15:09  3%   ` Uwe Brauer
2022-04-05 10:18     [BUG] Exporting italic link with bang inside to html fails to parse the link [9.5.2 (N/A @ /gnu/store/89yvbijwnvsbpa5h33mvbgh1gy9w30n2-emacs-org-9.5.2/share/emacs/site-lisp/org-9.5.2/)] Dr. Arne Babenhauserheide
2022-04-30  9:37     ` Ihor Radchenko
2022-04-30 11:47  5%   ` Max Nikulin
2022-04-10  8:49  9% Save Gnus attachments to Org using org-attach and helm-org-ql Juan Manuel Macías
2022-04-12  0:46  4% #+latex_header blocks, or, managing lots of LaTeX headers William Denton
2022-04-12  2:51  0% ` Vikas Rawal
2022-04-12  6:16  0% ` Tim Cross
2022-04-12  8:55  8% ` Juan Manuel Macías
2022-04-16  5:17     [PATCH] org-element-export-snippet-parser: Fix snippets without ending @@ Ihor Radchenko
2022-04-16 10:46 10% ` Juan Manuel Macías
2022-04-26 14:00  9% [tip] Org speed commands improved Juan Manuel Macías
2022-04-27  4:20  6% ` Ihor Radchenko
2022-04-27  5:37  0%   ` Tim Cross
2022-04-27  7:08  9%   ` Juan Manuel Macías
2022-05-04 22:12  6%     ` TRS-80
2022-04-27 16:30  6% ` Daniel Fleischer
2022-04-29 15:03  7% Org as a workspace (an impromptu reflection) Juan Manuel Macías
2022-04-29 23:46  6% ` Matt
2022-05-02 19:17  6% ` Nick Dokos
2022-05-03 23:41 10%   ` Juan Manuel Macías
2022-04-30 11:25  9% [PATCH] speed commands: error message when a key is not associated with a command Juan Manuel Macías
2022-04-30 13:06  6% ` Ihor Radchenko
2022-04-30 14:41  8%   ` Juan Manuel Macías
2022-04-30 19:39  8%     ` Juan Manuel Macías
2022-05-01  4:01  5%     ` Ihor Radchenko
2022-05-01 11:00  9%       ` Juan Manuel Macías
2022-05-02  3:31  6%         ` Ihor Radchenko
2022-05-03 23:08  8%           ` Juan Manuel Macías
2022-05-07 14:31  8% [PATCH] org-attach: Attach current Gnus article parts Juan Manuel Macías
2022-05-08 12:30  5% ` Ihor Radchenko
2022-05-08 13:23  9%   ` Juan Manuel Macías
2022-05-08 14:18  5%     ` Ihor Radchenko
2022-05-08 18:06 10%       ` Juan Manuel Macías
2022-05-07 23:43     Export LaTeX command inside figure environment Thomas S. Dye
2022-05-08  0:30 10% ` Juan Manuel Macías
2022-05-08  0:57  7%   ` Thomas S. Dye
2022-05-08  5:08  5%   ` Max Nikulin
2022-05-08  6:06  0%     ` Thomas S. Dye
2022-05-08 16:12  8%       ` Juan Manuel Macías
2022-05-08 22:22  7% [tip] Insert arbitrary LaTeX code at the beginning of any float environment Juan Manuel Macías
2022-05-09 12:47  6% ` Ihor Radchenko
2022-05-09 14:01 10%   ` Juan Manuel Macías
2022-05-09 14:14  6%     ` Eric S Fraga
2022-05-10 10:32  7% A function that converts a LaTeX document to an Elisp expression (for org-latex-classes) Juan Manuel Macías
2022-05-12  7:13     export to latex: begin_example gets exported to verbatim ( Uwe Brauer
2022-05-12  7:31     ` Eric S Fraga
2022-05-12  8:05       ` Uwe Brauer
2022-05-12  8:52 10%     ` Juan Manuel Macías
2022-05-12 10:02  0%       ` Uwe Brauer
2022-05-12 10:44  9% citation-style-language: new LaTeX package in TL 2022 Juan Manuel Macías
2022-05-12 11:34  6% ` Bruce D'Arcus
2022-05-13 16:37     simple request letter - help Andrés Ramírez
2022-05-13 17:04 10% ` Juan Manuel Macías
2022-05-13 17:19  2%   ` andrés ramírez
2022-05-13 18:22  8%     ` Juan Manuel Macías
2022-05-13 19:06  3%       ` andrés ramírez
2022-05-13 20:30  9%         ` Juan Manuel Macías
2022-05-14 19:58     I can't set dabbrev to respect the writen case Ypo
2022-05-14 22:32 10% ` Juan Manuel Macías
2022-05-15 10:40  7%   ` Ypo
2022-05-15 13:58 10%     ` Juan Manuel Macías
2022-05-15 11:54  9% [tip] Export and open a PDF in Android via Termux Juan Manuel Macías
2022-05-16 12:35  6% ` Ihor Radchenko
2022-05-16 15:00  6% ` Max Nikulin
2022-05-16 16:05 10%   ` Juan Manuel Macías
2022-05-17 16:22  5%     ` Max Nikulin
2022-05-17 17:56  8%       ` Juan Manuel Macías
2022-05-18 16:14  6%         ` Max Nikulin
2022-05-19  9:40  6%         ` Eric S Fraga
2022-05-19 18:01  8%           ` Juan Manuel Macías
2022-05-23 14:30  8% About 'inline special blocks' Juan Manuel Macías
2022-05-23 15:20  4% ` Kaushal Modi
2022-05-23 21:06  9%   ` Juan Manuel Macías
2022-05-24  2:36  6%     ` Tim Cross
2022-05-24  3:56           ` Ihor Radchenko
2022-05-25 13:55 10%         ` Juan Manuel Macías
2022-06-17  6:28             ` Ihor Radchenko
2022-06-17 19:49 10%           ` Juan Manuel Macías
2022-06-19 12:47  7%   ` Juan Manuel Macías
2022-06-19 19:30  5%     ` Christian Moe
2022-06-19 20:15  9%       ` Juan Manuel Macías
2022-06-19 22:18  5%     ` Tim Cross
2022-05-26 10:01  5% [tip] org-publish to work with (very) large books Juan Manuel Macías
2022-05-26 12:46  6% ` Christian Moe
2022-05-26 13:11       ` Ihor Radchenko
2022-05-26 13:48  8%     ` Juan Manuel Macías
2022-05-26 17:47  6%       ` Christian Moe
2022-05-27  4:19  6%       ` Ihor Radchenko
2022-05-27 11:39  8%         ` Juan Manuel Macías
2022-05-28  3:02  5%           ` Ihor Radchenko
2022-05-28  8:59  6%             ` Juan Manuel Macías
2022-05-29 12:15  5%               ` Ihor Radchenko
2022-05-29 18:01  6%                 ` Juan Manuel Macías
2022-05-27 16:23     how to export an org file, to 2 different locations (in to different formats) Uwe Brauer
2022-05-27 18:42  9% ` Juan Manuel Macías
2022-05-28  0:18 10%   ` Juan Manuel Macías
2022-05-28  6:36  0%     ` Uwe Brauer
2022-05-28  7:23  8%       ` Juan Manuel Macías
2022-05-28  8:40  1%         ` Uwe Brauer
2022-05-28  9:06 10%           ` Juan Manuel Macías
2022-05-28 14:58     # Comments export Ypo
2022-05-28 15:44     ` Timothy
2022-05-28 15:58       ` Ypo
2022-05-28 16:05         ` Timothy
2022-05-28 23:15           ` Samuel Wales
2022-05-29  0:46             ` Ypo
2022-05-30  7:35               ` Eric S Fraga
2022-05-30 10:46 10%             ` Juan Manuel Macías
2022-05-30 21:49  5%               ` Tim Cross
2022-06-08  9:59     Org-attach for a directory Cletip Cletip
2022-06-08 10:32  9% ` Juan Manuel Macías
     [not found]       ` <CAPHku6O3RojzhaSu3d2pWfnE8x7N_9WAfjCupHyKcxNyD-i=ew@mail.gmail.com>
2022-06-09 10:11  8%     ` Juan Manuel Macías
2022-06-10 18:28  8% [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments' Juan Manuel Macías
2022-06-11  5:39  6% ` Ihor Radchenko
2022-06-11 11:20  9%   ` Juan Manuel Macías
2022-06-14  3:58  6%     ` Ihor Radchenko
2022-06-14 11:11  8%       ` Juan Manuel Macías
2022-06-14 11:55  6%         ` Ihor Radchenko
2022-06-15 10:30  9%           ` Juan Manuel Macías
2022-06-12 19:18  6% ` Rudolf Adamkovič
2022-06-12 19:55  9%   ` Juan Manuel Macías
2022-06-13  8:24  6%     ` Rudolf Adamkovič
2022-06-13 10:22 10%       ` Juan Manuel Macías
2022-06-17 12:47     Utility of description lists Cletip Cletip
2022-06-17 14:24  9% ` Juan Manuel Macías
2022-06-18 14:35  7% [Tip] Screenshots as org links with EMMS and socat Juan Manuel Macías
2022-06-19 15:50     Keybinding doubt about ARG Ypo
2022-06-19 16:49     ` Bruno Barbier
2022-06-19 17:21 10%   ` Juan Manuel Macías

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).