* Re: convert subtree or nested list to table
@ 2021-07-05 20:01 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-05 20:01 UTC (permalink / raw)
To: Matt Price; +Cc: orgmode
Hi Matt,
Matt Price writes:
> I have to write a number of text-heavy documents which need to be
> delivered as tables with wrapped paragraphs in most cells. Working
> directly in table format is pretty arduous and uncomfortable. Has
> anyone ever written a function to accept a list or subtree as input
> and process it into a table?
>
> If anyone has done something similar, I'd love some tips!
Some time ago I wrote some functions for my personal use that allow edit
table cells (with a lot of text and/or paragraphs) in a dedicated
buffer. I don't know if something like that is what you are looking for,
but if you are interested, I can clean up the code a bit and upload it
here.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Virtually prefix headlines according to content
@ 2021-06-29 13:34 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-29 13:34 UTC (permalink / raw)
To: Rodrigo Morales; +Cc: orgmode
Rodrigo Morales writes:
> What I would like to know is whether it is possible to format a headline
> by taking into consideration the properties it has. For example, in this
> specific scenario, I would like to make all headlines that have a
> "GITHUB" to show "GH" before the actual headline (the content would look
> like this).
You can define a function with `org-map-entries' that adds (for example) a
tag :github: to all headers with the property GITHUB:
#+begin_src emacs-lisp
(defun add-github-tag ()
(interactive)
(org-map-entries (lambda ()
(save-restriction
(save-excursion
(org-narrow-to-subtree)
(goto-char (point-min))
(end-of-line)
(insert " :github:"))))
"+GITHUB={.+}"))
(add-hook 'org-mode-hook #'add-github-tag)
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: appearance of list as results from evaluating code blocks
@ 2021-06-23 19:43 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-23 19:43 UTC (permalink / raw)
To: Johannes Brauer; +Cc: orgmode
Hi Johannes,
Johannes Brauer writes:
> Hi!
> Evaluating a code block containing a list expression using org-babel for elisp or Clojure, for example
> (list 1 2 3)
> I get
> #+RESULTS:
> | 1 | 2 | 3 |
> I would prefer
> #+RESULTS:
> ( 1 2 3 )
>
> Is it possible to get this.
Try
#+begin_src emacs-lisp :results raw
(list 1 2 3)
#+end_src
#+RESULTS:
(1 2 3)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Write Markdown in Org mode
@ 2021-06-12 15:51 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-12 15:51 UTC (permalink / raw)
To: leo; +Cc: orgmode
Hi Leo,
leo writes:
> Good to know. I’m not too keen to learn yet another text markup language, but I might give org mode a try…
It's worth a try! Org markup language is very similar to Markdown. My
advice is that you take from Org only what you need, because Org has so
many features that at first it can saturate you. A Recommended initial
reading may be the compact guide, which gives you a pretty global vision
without going too deep in each aspect: https://orgmode.org/guide/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Failure to resolve internal links on ox-html export?
@ 2021-06-11 18:31 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-11 18:31 UTC (permalink / raw)
To: Tim Visher; +Cc: orgmode
Hi Tim,
Try setting this variable to non-nil:
(setq org-export-with-broken-links t)
Best regards,
Juan Manuel
Tim Visher writes:
> Hi Everyone,
>
> I'd like to be able to link to various areas of a large wiki file I
> maintain for when I'm looking at an entry in emacs. However, I will
> often email exported subtrees and when I do that if I have a link to a
> heading that's outside the current subtree it fails with a
> `user-error: Unable to resolve link: …`, I assume because the export
> tree doesn't contain that heading.
>
> Is there any way to tell the exporter to simply make those into plain
> text _or_ to simply ignore the error?
>
> Thanks in advance!
>
> --
>
> In Christ,
>
> Timmy V.
>
> https://blog.twonegatives.com
> http://five.sentenc.es
>
^ permalink raw reply [relevance 10%]
* org-critical-edition (a package for philologists and classicists)
@ 2021-06-07 13:09 10% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-07 13:09 UTC (permalink / raw)
To: orgmode
Hi all,
I have uploaded the (very) initial version of my package
org-critical-edition:
https://gitlab.com/maciaschain/org-critical-edition
This package lets you prepare a philological critical edition in Org
Mode. The natural output is LaTeX with the reledmac package
(https://www.ctan.org/pkg/reledmac).
(For those who are not philologists, this is an example of critical
edition that I typesetted recently: https://imgur.com/a/drqCib5)
Feedback welcome!
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: literate programming, development log -- ideas?
@ 2021-06-07 12:00 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-07 12:00 UTC (permalink / raw)
To: Greg Minshall; +Cc: orgmode
Hi Greg,
Greg Minshall writes:
> but i also feel a need for something that might be called a lab
> notebook, a development log, of ideas, including dead ends, i pursue
> during the development process, with links, etc.. but, i'm not really
> sure how to structure this bit, how to integrate it in the rest of the
> .org file -- i.e., as a separate heading, or related to the code section
> that (originally) was under development when the notes were created.
> or...? etc.
I use `org-add-note' a lot, in a wide variety of scenarios. According to their
docstring:
"Add a note to the current entry.
This is done in the same way as adding a state change note."
And I've set (setq org-log-into-drawer t)
On the other hand, maybe you can find interesting the org-marginalia package:
(https://github.com/nobiot/org-marginalia).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] Allow LaTeX reference command (\ref) to be customised
@ 2021-06-06 18:29 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-06 18:29 UTC (permalink / raw)
To: Timothy; +Cc: orgmode
Hi Timothy,
Timothy writes:
> I've started doing some more cross-referencing in documents exported to
> LaTeX, and a hardcoded use of \ref has begun to stand out to me as a
> rather annoying thing. Hypperef provides \autoref for adding helpful
> prefixes (section, figure, etc.), and there are other packages which one
> may want to use to generate 'clever' references (like cleveref with
> \cref).
>
> As such, I think that the hardcoded \ref should actually be turned into
> a customisable format string, which is what the attached patch does.
I think it's a great idea. There are many options in LaTeX to manage
cross references, beyond the standar \ref. I use the varioref package a
lot (https://www.ctan.org/pkg/varioref).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part
@ 2021-06-03 21:11 10% Juan Manuel Macías
2021-06-04 11:31 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-03 21:11 UTC (permalink / raw)
To: orgmode
Hi all,
In master:
if I do:
(org-link-set-parameters "foo"
:display 'full
:face '(:foreground "chocolate" :weight bold :underline t))
and then:
[[foo:target][description]]
the face parameter is only applied in the description part.
Expected result: shouldn't the face be applied to the entire link?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: suggestion to change default org-latex-pdf-process to latexmk
@ 2021-06-02 8:40 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-02 8:40 UTC (permalink / raw)
To: Stefan Nobis; +Cc: orgmode
Stefan Nobis writes:
> An alternative may be to use latexmk only if citations are found (new
> feature, new dependencies). Or a wrapper that checks whether latexmk
> is available and works (e.g. trying to call "latexmk --version") and
> falls back to the old routine of manually running the engine and
> bibtex/biber if necessary.
Another possibility would be to add to the documentation all the
instructions needed on how to properly configure `org-latex-pdf-process'
with latexmk, for those users who wish to use bibtex or biblatex.
Although latexmk is also useful for many packages that need multiple
compilations, indexes, etc.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: suggestion to change default org-latex-pdf-process to latexmk
@ 2021-06-01 15:52 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-01 15:52 UTC (permalink / raw)
To: Bruce D'Arcus; +Cc: orgmode
Hi Bruce,
Bruce D'Arcus writes:
> So what do LaTeX users think about changing the default for
> "org-latex-pdf-process" to "latexmk"?
It sounds like a good idea to me. In fact I have `org-latex-pdf-process'
set to latexmk in my ~ /.emacs (with the option to always compile with
LuaTeX).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: TMIO Pre-release, request for feedback
@ 2021-05-30 19:42 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-30 19:42 UTC (permalink / raw)
To: Timothy; +Cc: orgmode
Hi Timothy,
Timothy writes:
> Hi Everyone,
>
> As we arrive at the end of May, I'm about to publish the 3rd issue of
> /This Month in Org/. I thought I'd share the current draft with the list
> the day before I publish to so that those of you who are interested have
> the chance to point out any errors, let me know if there's anything I
> haven't covered that you'd like to see, along with any other feedback
> you may have.
>
> For the next day, you can find the draft at:
> https://blog.tecosaur.com/tmio/DRAFT-2021-05-31.html
> and then once published it will live at:
> https://blog.tecosaur.com/tmio/2021-05-31.html
Thank you very much for your excellent work, and for all the effort and
time you put in it. I think your /This Month in Org/ conveys, above all,
something very valuable that all Org users share: an immense and
uncompromising enthusiasm for Org and Emacs :-D
I like the design of the site: very clear and readable.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Smart quotes not working correctly with single quotes
@ 2021-05-28 20:37 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-28 20:37 UTC (permalink / raw)
To: Andreas Gösele; +Cc: orgmode
Hi Andreas,
Andreas Gösele writes:
> I tried it, but it doesn't work. It leaves the simple quotes
> untouched. Did you test it and did it work then?
I forgot to tell you (sorry!) that you should set the variable
`org-export-allow-bind-keywords' as non-nil:
(setq org-export-allow-bind-keywords t)
If you are going to use that filter in many documents, you can better add to your
~ /.emacs:
(add-to-list 'org-export-filter-final-output-functions 'single-quote-filter)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [org-footnote--allow-reference-p]
@ 2021-05-20 10:38 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-20 10:38 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Ah! That was it, thanks!
> I think the documentation of org-footnote-action
> could be a bit more explicit and cover this case.
In the manual the use of the zero width space character is in the section
'Escape Character'. Perhaps it would be nice to add more usage examples. A
very typical (and practical) use is when you want to emphasize a part of a
word:
with /meta/<zero-with-space>literature you get (LaTeX)
\emph{meta}literature instead of the literal /meta/literature...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [org-footnote--allow-reference-p]
@ 2021-05-20 10:17 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-20 10:17 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe,
Uwe Brauer writes:
> It seems that the function org-footnote--allow-reference-p
> is the culprit, but which places are *forbidden* the doc string does not
> say much.
If you mean to insert a note in an empty cell, you can insert just
before the note mark a zero width space (M-x insert-char RET 200b RET)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Multilingual support (proposals and state of the question)
@ 2021-05-17 18:10 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-17 18:10 UTC (permalink / raw)
To: Denis Maier; +Cc: orgmode
Hi Denis,
Denis Maier writes:
> Why not add a :lang property to other blocks as well?
>
> #+begin_quote :lang en
> this is english.
> #+end_quote
>
> WDYT?
>
> Denis
It's an interesting possibility. However, I think that the advantage of
Org src blocks is that you can include anything you want, even quote
blocks. And you also have org-edit-special...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: How to create a macro that inserts multiline text with :B_ignoreheading: tag?
@ 2021-04-30 20:40 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-30 20:40 UTC (permalink / raw)
To: Richard Stanton; +Cc: orgmode
Hi Richard,
Richard Stanton <rhstanton@berkeley.edu> writes:
> I’d like to define a macro called, say, articletext, to insert this
> header into my document before exporting to LaTeX, so the org file
> would look something like this:
>
> {{{article text}}}
> This text appears only in the article version.
Macro definitions do not allow spaces.
You can try something like:
#+MACRO: article_text (eval (concat "*** More explanation coming" "\s" ":B_ignoreheading:\n:PROPERTIES:\n:BEAMER_env: ignoreheading\n:END:"))
{{{article_text}}}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [patch] to allow org-attach-git to handle individual repositories
@ 2021-04-28 13:42 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-28 13:42 UTC (permalink / raw)
To: Bastien; +Cc: orgmode
Hi Bastien,
Bastien writes:
> It looks good but it is significative enough to require you to sign
> the FSF copyright assignment. If you're willing to go through this
> (which will secure future contributions too), please see:
Thanks for the advice. I just signed and sent the FSF copyright
assignment.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [tip] search this mailing list with helm-surfraw
@ 2021-04-27 20:20 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-27 20:20 UTC (permalink / raw)
To: Bastien; +Cc: orgmode
Hi Bastien,
Bastien writes:
> Neat!
>
> You might want to write another one for the public-inbox archive:
>
> E.g. https://orgmode.org/list/?q=Juan+Manuel+Mac%C3%ADas
I was unaware that searches in the public-box archive are faster...
Thank you very much for the advice :-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] Startup option to separate macros arguments with an alternative string
@ 2021-04-22 13:46 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-22 13:46 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hi Nicolas,
Thank you very much for your suggestions.
Nicolas Goaziou writes:
> This change will need to be tested extensively in "test-org-element.el"
> and "test-org-macro.el".
>
> However, as a start, I suggest starting a new thread about a suggested
> change in the syntax, with a clear title, examples, and code. Then we
> can leave time for users to react to it.
>
> Do you want to take care of it?
Ok, I agree. Next week I will start a new thread for submit this new
proposal.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-12 23:18 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-12 23:18 UTC (permalink / raw)
To: Ypo; +Cc: orgmode, Nicolas Goaziou
Hi Ypo,
Ypo writes:
> This is my result after doing "org-sort-list a":
>
> - /a/
> - /v/
> - a
> - b
>
> Regards
Thanks for trying. So it seems that you can reproduce the problem as
well... I wonder if anyone else is able to reproduce it, preferably in a
minimal emacs.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-12 13:50 10% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-12 13:50 UTC (permalink / raw)
To: orgmode
Nicolas Goaziou writes:
> I cannot reproduce it. With your initial list, and a minimal init file,
> I get:
>
> - /a/
> - a
> - b
> - /v/
>
> Could you try with a minimal Emacs, too?
That's weird ... I have tried launching emacs -q in a virtual machine,
and I keep getting the wrong result (git version, master branch):
- /a/
- /v/
- a
- b
I have tried with the typical keyboard shortcut and also with M-: and
evaluating (org-sort-list t? a nil nil nil)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
@ 2021-04-07 19:52 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-07 19:52 UTC (permalink / raw)
To: physiculus; +Cc: orgmode
Hello again,
physiculus writes:
> Yes that works!
> usually i do not use imagemagick. I use graphicsmagick, but ido not know
> how i have to set the right command line.
> SVG does nothing.
> Very sad :-(
> I want to use this because of quality reasons.
> Do you know, how i can test svg?
the dvisvgm option with luatex is definitely wrong, since dvisvgm does
not support opentype fonts. Sorry for having you confused with my other
snippet. The good news, it seems, is that dvisvgm will support opentype
fonts as of version 2.10, which I assume the next version of texlive
will include it. The actual version is 2.9.1 (command dvisvgm
--version).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
@ 2021-04-06 20:09 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-06 20:09 UTC (permalink / raw)
To: tomas; +Cc: orgmode
Hi Tomas,
tomas@tuxteam.de writes:
> AFAIK Lua(La)Tex can output dvi (and Juan Manuel's answer implies
> thati, too). Either via the option --output-format=dvi or invoking
> it as "dviluatex".
>
> But perhaps I missed something.
Yes, the first option I have commented in my previous mail (setq
luamagick etc ...) converts from pdf to png via 'convert' (imagemagick);
in the second option (setq luasvg etc ...) compiles with the option
`-output-format dvi' and then the converter is dvisvgm.
Best regards,
Juan Manuel
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 10%]
* Re: First steps exporting to tex
@ 2021-04-04 11:36 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-04 11:36 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Ypo writes:
> I've already tried that. But it doesn't seem to understand the HOME
> directory ~~/~. At least at Windows.
I haven't touched Windows for a thousand years :-), but maybe this thread
can help you:
https://stackoverflow.com/questions/13584118/how-to-write-a-path-with-latex
best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: how to export (latex) a image without using figure
@ 2021-04-04 11:17 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-04 11:17 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe,
Try:
#+ATTR_LaTeX: :float nil
#+CAPTION: La función La función $x^2 e^{-\alpha x} = \frac{1}{\alpha}$, $\alpha=-\ln(1-p)$ con $p=0.01$ con $p=0.3$
[[./images/dfp_03.png]]
Best regards,
Juan Manuel
Uwe Brauer writes:
> Hi
>
> Currently
>
> #+CAPTION: La función La función $x^2 e^{-\alpha x} = \frac{1}{\alpha}$, $\alpha=-\ln(1-p)$ con $p=0.01$ con $p=0.3$
> #+NAME: fig:plotcalor23
>
> [[./images/dfp_03.png]]
>
> Gets translated to
>
> \begin{figure}[htbp]
> \centering
> \includegraphics[width=.9\linewidth]{./images/dfp_03.png}
> \caption{\label{fig:plotcalor23}La función La función \(x^2 e^{-\alpha x} = \frac{1}{\alpha}\), \(\alpha=-\ln(1-p)\) con \(p=0.01\) con \(p=0.3\)}
> \end{figure}
>
> For reasons that needs a longer explanation I would need.
>
>
>
> \includegraphics[width=.9\linewidth]{./images/dfp_03.png}
> \captionof{figure}{\label{fig:plotcalor23}La función La función \(x^2 e^{-\alpha x} = \frac{1}{\alpha}\), \(\alpha=-\ln(1-p)\) con \(p=0.01\) con \(p=0.3\)}
>
>
> How can this be achieved?
>
> Thanks
>
> Uwe Brauer
>
>
>
>
^ permalink raw reply [relevance 10%]
* Re: How to get a table into a variable in a shell code block?
@ 2021-04-03 19:01 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-03 19:01 UTC (permalink / raw)
To: Greg Minshall; +Cc: orgmode
Hi Greg and William,
Greg Minshall writes:
> William,
>
> try
>
> #+begin_src shell :results output :var n=numbers
> echo ${n[1]}
> #+end_src
>
> cheers, Greg
I don't know if I'm saying something wrong, but wouldn't it be better
this way?:
#+begin_src shell :results output :var n=numbers
echo ${n[@]}
#+end_src
echo ${n[1]} returns the second element (two) of the list (0, returns
one and 2 returns three)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Including Email Address in the Reply in Mailing-list
@ 2021-04-02 23:45 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-02 23:45 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross writes:
> I have no issue with this suggestion and am happy to try and comply.
>
> The challenge for many will be that they either
>
> - need to remember to remove the email details manually (line/header
> automatically added by mail client) while sorting out either
>
> - how to modify mail client for all replies (may not be appropriate for
> non-ML replies), or
>
> - how to modify mail client for just ML replies
> [...]
For Gnus users, one possibility might be:
(defun my-gnus-reply-ml ()
(interactive)
(let*
((message-citation-line-format "%N writes:\n")
(message-citation-line-function 'message-insert-formatted-citation-line))
(gnus-article-reply-with-original)))
...And then assign any free key to gnus-article-mode-map
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: About exporting
@ 2021-03-31 18:56 10% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-31 18:56 UTC (permalink / raw)
To: orgmode
Martin Steffen <msteffen@ifi.uio.no> writes:
> [...] And last not least; if I ``compile'' the document (firing off latex,
> bibtex, or index or whatever), the compilation runs in the background.
> As far as I do that in org (exporting to pdf), it blocks emacs. Not
> that it's a huge delay even, at least for smaller documents, I hate
> that an editor or some tool is slower than me, it gets on my nerves if
> the computer slows me down.
There is the async-export (C-a) option in org-export-dispatcher.
Anyway, I usually use the latexmk script a lot, even with Org
(combined with Org Publish: I export sub-documents to *tex from Org and
compile later with latexmk the master document. latexmk with the -pvc
options is wonderful.
I agree that AUCTeX is excellent; maybe (IMHO) the best LaTeX editor out
there.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: "Org" source blocks and minted
@ 2021-03-26 11:55 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-26 11:55 UTC (permalink / raw)
To: Timothy; +Cc: orgmode
Hi Timothy,
I really like your approach. And it is org/emacscentric! Minted has
never quite convinced me, and gives me some trouble with certain
packages in LuaLaTeX that I have not been able to solve. Thank you for
this promising alternative.
Best regards,
Juan Manuel
Timothy <tecosaur@gmail.com> writes:
> Juan mentioned an Org lexer exists, but another approach that may be of
> interest is using Emacs' own font-lock. I wrote a package that's like
> HTMLize but works with LaTeX and currently have it sitting in my config.
>
> I plan on submitting a patch to Org at some point on this, but for now:
> - https://github.com/tecosaur/engrave-faces
> - https://tecosaur.github.io/emacs-config/config.html#pretty-code-blocks
>
> Sample output: all the code blocks in
> https://tecosaur.github.io/emacs-config/config.pdf
>
> Since this uses Emacs' font-lock, this means that you can use any
> language that you have a syntax-highlighting-mode for :)
^ permalink raw reply [relevance 10%]
* Re: "Org" source blocks and minted
@ 2021-03-24 4:18 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-24 4:18 UTC (permalink / raw)
To: Michael Gauland; +Cc: orgmode
Hi Mike,
Michael Gauland <mikelygee@gmail.com> writes:
> I want to include an "org" source block in a document as an example,
> and have it formatted with minted. Unfortunately, minted doesn't seem
> to recognize "org" as a language,and the block is missing in the
> resulting PDF. For the moment, I've changed this to a "text" source
> block, but it would be nice to have syntax highlighting in the export.
>
> Have any of you done this, or something similar?
>
> Kind regards,
> Mike
>
You can write your own pygments lexer:
https://pygments.org/docs/lexerdevelopment
But it seems that someone already did the work of writing a lexer for
Org Mode:
https://github.com/or/pygments-orgmode-lexer
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Items with emphasis marks are not sorted properly in a list
@ 2021-03-22 21:59 10% Juan Manuel Macías
2021-03-23 8:36 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-22 21:59 UTC (permalink / raw)
To: orgmode
Hi,
Consider this list:
- vol.
- adj.
- /circa/
- /vid./
If I evaluate `(org-sort-list t ?a)', it seems that `org-sort-list'
doesn't sort correctly items that contain an emphasis mark:
- /circa/
- /vid./
- adj.
- vol.
I don't know if there is any solution to this, or if I'm doing something wrong...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-19 8:44 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-19 8:44 UTC (permalink / raw)
To: tomas; +Cc: orgmode
Hi Tomas,
<tomas@tuxteam.de> writes:
> If the aim is "just rendering in Org" and "breaks have no special
> meaning" (so each render is allowed to re-flow), then your approach
> makes sense (I think Org table has something like that: you can
> set the column width and shrink/expand the column appropriately.
> Personally, I've found that somewhat awkward, so I don't use it,
> but OTOH I'm not a heavy table user: perhaps that's why).
I was writing yesterday some rudimentary code (just a proof of concept)
and I've made this screencast:
https://lunotipia.juanmanuelmacias.com/edit-cell-sample-2021-03-19_09.29.17.mp4
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-18 15:15 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-18 15:15 UTC (permalink / raw)
To: Atlas Cove; +Cc: orgmode
Atlas Cove <Atlas48@gmx.com> writes:
> In effect, yes. I'm proposing it as a syntax addition to make it easier to read, export, and manage, larger tables.
> I'm unsure if this would fit within the scope of org, but [[https://github.com/RedBug312/markdown-it-multimd-table][other projects]],
> like [[https://fletcher.github.io/MultiMarkdown-6/MMD_Users_Guide.html#tables][MultiMarkdown]] have exactly what I want in terms of table use.
> Since I've already proposed a single, solitary addition to org, we won't discuss all of those nice features /just/ yet!
Thanks for your clarification. I strongly support your proposal.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: printing org table landscape on complete page
@ 2021-02-28 20:53 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-28 20:53 UTC (permalink / raw)
To: Andrés Ramírez; +Cc: orgmode
Hi,
You can use:
#+ATTR_LaTeX: :float sideways
which is exported to LaTeX with the sidewaystable environment (rotating
package).
And for the table to fit vertically on the page:
#+LaTeX_Header: \usepackage{tabularx}
#+ATTR_LaTeX: :float sideways :environment tabularx :width \textheigtht
Regards,
Juan Manuel
Andrés Ramírez <rrandresf@gmail.com> writes:
> Hi.
>
> I want to print from emacs an org-table like this one:
>
> |-------------+-----------+----------+-----------+----------+---------|
> | DURATION | MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY |
> |-------------+-----------+----------+-----------+----------+---------|
> | 08:30-09:30 | CyT | RELIGION | GERMAN | ENGLISH | ENGLISH |
> |-------------+-----------+----------+-----------+----------+---------|
> | 09:50-10:50 | COMUNICAT | DPCC | COMUNICAT | COMUNIC | CyT |
> |-------------+-----------+----------+-----------+----------+---------|
> | 11:10-12:10 | COMPUTERS | CyT | E.FISICA | ART | GERMAN |
> |-------------+-----------+----------+-----------+----------+---------|
> | 12:30-13:30 | TUTORIA | MATH | MATH | CC.SS | MATH |
>
> on landscape on the content should enlarge to cover the full-page.
>
> Any ideas?
>
> Andrés Ramírez
>
^ permalink raw reply [relevance 10%]
* Re: 'false' list item
@ 2021-02-21 22:25 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-21 22:25 UTC (permalink / raw)
To: Samuel Wales; +Cc: orgmode
Samuel Wales <samologist@gmail.com> writes:
> perhaps if there is no blank line above or below, then it could be not a list.
I think this solution would be fine, although plain paragraphs starting
with digit/letter + period + space would be false positives. Anyway,
some kind of highlighting in the items, a defined face as in
markdown-mode (markdown-list-face), would be also helpful.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: 'false' list item
@ 2021-02-21 14:49 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-21 14:49 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Hi,
Tim Cross <theophilusx@gmail.com> writes:
> If a line starts with a number, period and space, but that line is
> within a paragraph (i.e. no blank line above), then I don't think it
> should be interpreted as an enumerated list item. If this is what the OP
> is referring to, I would argue it is a bug. If it is a 'paragraph'
> starting with a number, period and space, then being interpreted as a
> list item would be 'normal'.
The problem occurs on the lines within a paragraph (no blank line
above). I have uploaded this screenshot:
https://gnutas.juanmanuelmacias.com/images/false-list-item.webm
It also happens with a clean startup.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [question] lisp code in :results header arg.?
@ 2021-02-16 18:25 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-16 18:25 UTC (permalink / raw)
To: Berry, Charles; +Cc: orgmode
"Berry, Charles" <ccberry@health.ucsd.edu> writes:
> I think you might do better to use noweb chunks, viz.
>
> #+name: pre-amble
> #+begin_src latex :exports none
>
> \usepackage{luacode}
> \usepackage{fontspec}
> \directlua
> {
> [...]
> }
> }
> \setmainfont{Linux Libertine O}
> [RawFeature={+ktest}]
> #+end_src
>
> #+begin_src latex :noweb yes :results drawer
> ,#+LaTeX_HEADER: <<pre-amble>>
> #+end_src
>
>
> Evaluating the latter chunk (assuming `org-babel-load-languages' has (latex . t)) gives what I suspect you want.
wow, it works great! Many thanks. I did not know this use of noweb ...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: http links translated to html : target "_blank"
@ 2021-02-01 21:01 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-01 21:01 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer <oub@mat.ucm.es> writes:
> That is odd (maybe my org version is a bit rusty (master june 2020)
It's strange...
It should work fine for you (as long as you set
`org-export-allow-bind-keywords' as non-nil)
You can also try `org-export-filter-link-functions' instead of
`...-final-output-functions'.
Anyway, if the `#+attr_latex' solution works for you, then all is fine.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: org-attach-git don't automatically commit changes
@ 2021-01-31 14:36 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-31 14:36 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko <yantar92@gmail.com> writes:
> What is more tricky is making sure that workflow for people using the
> old behaviour is not broken. Just changing to (org-attach-dir) will
> break existing git repos in org-attach-id-dir. This should also not be
> too hard (say, we can introduce a custom variable defaulting to old
> behaviour), but exact details may need to be discussed.
I agree: I think a custom variable with the current behavior by default
would be fine.
> In any case, if you provide a patch, it will encourage the org
> maintainers to join this discussion and proceed with changes.
OK, this week I will try to propose a patch here, and bring it up for
(possible) discussion. Thanks for the suggestions.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: org-attach-git don't automatically commit changes
@ 2021-01-31 11:41 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-31 11:41 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko <yantar92@gmail.com> writes:
> I think you misunderstood how org-attach-git works.
>
> org-attach-git is:
>
> ;; An extension to org-attach. If `org-attach-id-dir' is initialized
> ;; as a Git repository, then org-attach-git will automatically commit
> ;; changes when it sees them. Requires git-annex.
>
> So, it is not designed to work when your actual attachment directory is
> a git repo, but rather when org-attach-id-dir is a git repo (initialised
> manually).
Thanks for the explanation: it is clear that I had misinterpreted
`org-attach-id-dir'. Now it makes sense that it didn't work for me.
Anyway, I think the manual at that point is somewhat ambiguous and it
should be more precise, IMHO.
> So, I believe that org-attach-git should be updated. Probably,
> handling attachment dirs as individual git repos can be one of the
> ways to upgrade the current version.
I agree, I think this possibility makes a lot more sense.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Region-based meta-notes
@ 2021-01-19 22:39 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-19 22:39 UTC (permalink / raw)
To: Lawrence Bottorff; +Cc: orgmode
Hello,
Lawrence Bottorff <borgauf@gmail.com> writes:
> So yes, simply being able to select regions and make side notes about
> them could give you a very fine level of control over metadata in a
> file. Is there such a thing in the Emacs/org-mode world?
Take a look at the org-marginalia package:
https://github.com/nobiot/org-marginalia
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Org to ConTeXt exporter?
@ 2021-01-09 17:42 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-09 17:42 UTC (permalink / raw)
To: Jason Ross; +Cc: orgmode
Hello, Jason,
Jason Ross <jasonross1024@gmail.com> writes:
> I recently had the same thought and I've started working on one.
> You can see it here:
>
> https://github.com/Jason-S-Ross/ox-context/
>
> It's no substitute for the LaTeX exporter but it implements a lot
> of the basics. I'm deriving from the LaTeX exporter but I have
> to override most of the transcoders so it may be better to start
> from scratch.
>
> Disclaimer: I'm learning elisp as I go, so please excuse the
> rough edges.
That's great news! I've been testing it a bit and it works very good. Of
course, I encourage you to keep up this excellent work.
Regards,
Juan Manuel
>
> Jason Ross
>
--
^ permalink raw reply [relevance 10%]
* Re: Possibility to copy text outside EMACS and send it to orgmode document
@ 2021-01-06 16:31 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-06 16:31 UTC (permalink / raw)
To: Gerardo Moro; +Cc: orgmode
Gerardo Moro <gerardomoro37@gmail.com> writes:
> Basically that: as I copy (Control-C) text from the browser (Chrome),
> I would like those copied sentences to be sent to a ordered list in an
> OrgMode document:
>
> - copied text 1
> - copied text 2
> - etc.
>
> Any ideas? This would be very useful.
> Thanks!
I don't know if it is exactly what you are looking for, but maybe you
might be interested in this extension for chrome and firefox that uses
org-protocol:
https://github.com/sprig/org-capture-extension
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Inserting LaTex expressions using a filter fails
@ 2021-01-06 15:58 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-06 15:58 UTC (permalink / raw)
To: Mart van de Wege; +Cc: orgmode
Mart van de Wege <mart@vdwege.eu> writes:
> You're right. I looked up the variable, and there is only one mention
> in the docs, and that is about binding emacs variables locally to the
> org file buffer.
>
> Can I just clone the repo and prepare a patch?
As far as I know, you can create a diff and propose the patch here in
the list, opening a new thread, that includes in the mail subject
something like "[patch] etc"
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Inserting LaTex expressions using a filter fails
@ 2021-01-06 12:24 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-06 12:24 UTC (permalink / raw)
To: Mart van de Wege; +Cc: orgmode
Mart van de Wege <mvdwege@gmail.com> writes:
> Kind of weird it's not mentioned in the docs though (at least not in
> the same section as export filters); if you're going to tell people that
> you can bind local functions to an org file, then it might be nice to
> point out that you do need to turn that on.
You're right. I think an addition could be proposed in the
documentation: for example, a footnote in the section `Defining filters
for individual files', since by default the variable
`org-export-allow-bind-keywords' has value nil.
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Inserting LaTex expressions using a filter fails
@ 2021-01-06 11:51 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-06 11:51 UTC (permalink / raw)
To: Mart van de Wege; +Cc: orgmode
Mart van de Wege <mvdwege@gmail.com> writes:
> Thanks!
>
> But see my answer to Nick Dokos on the list, that does not do anything
> either.
Try putting this variable in your .emacs with non-nil value:
(setq org-export-allow-bind-keywords t)
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Inserting LaTex expressions using a filter fails
@ 2021-01-05 21:58 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-05 21:58 UTC (permalink / raw)
To: Mart van de Wege; +Cc: orgmode
Hello,
Mart van de Wege <mvdwege@gmail.com> writes:
> I'm trying to replace U+00BD in an org buffer with \sfrac{1}{2} during
> export to LaTex, and obviously I'm doing something wrong, or I don't
> understand the documentation.
>
> I use the following code to set up the filter:
>
> #+BIND: org-export-filter-item-functions (latex-replace-half)
> #+BEGIN_SRC emacs-lisp :exports results :results none
>
> (defun latex-replace-half (text backend info)
> (when (org-export-derived-backend-p backend 'latex)
> (replace-regexp-in-string "½" "\\sfrac{1}{2}" text)))
> #+END_SRC
You must add a double escape character to the backslash:
...
(replace-regexp-in-string "½" "\\\\sfrac{1}{2}" text)))
...
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Org to ConTeXt exporter?
@ 2020-12-28 18:03 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-28 18:03 UTC (permalink / raw)
To: Diego Zamboni; +Cc: orgmode
Hello, Diego,
Diego Zamboni <diego@zzamboni.org> writes:
> I have never used ConTeXt, but from what I've seen, despite its many
> differences, a lot is still similar to TeX/LaTeX (e.g. math). Given
> this, I think it might be easier to create a new derived exporter from
> ox-latex, and override the parts that differ, instead of creating a
> new one completely from scratch.
You are right, maybe it is better to start with ox-latex, since LaTeX
and ConTeXt are related.
> You can see an example in my own
> https://github.com/zzamboni/ox-leanpub/blob/master/ox-leanpub-markua.el,
> which uses ox-md as a backend for defining the new ox-markua exporter.
Thank you very much for the link. As soon as I have some time I will
study your code
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Bug: Tildes in URL impact visible link text [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
@ 2020-12-27 21:33 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-27 21:33 UTC (permalink / raw)
To: tomas; +Cc: orgmode
Hello,
<tomas@tuxteam.de> writes:
> This would be a bug: tilde is an allowed URI character [1]
You're right. I have also noticed that if I write links like these:
[[*foo ~foo~ foo]][[foo]]
[[*foo =foo= foo]][[foo]]
There is an anomaly in the description similar to what Chris comments in
his email...
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Bug: Tildes in URL impact visible link text [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
@ 2020-12-27 18:12 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2020-12-27 18:12 UTC (permalink / raw)
To: Chris Hunt; +Cc: orgmode
Hello,
I think the problem comes because in that url the tilde does not have an
escape character. If it's just that case, you can try replacing each
tilde with %7E (see
https://www.w3schools.com/tags/ref_urlencode.asp). That way the
link description would have to be formatted correctly, without spurious
characters.
Regards
Juan Manuel
Chris Hunt <chrahunt@gmail.com> writes:
> I'm trying to create a link in an org file with this URL:
>
> https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2:graph=~(view~'timeSeries~stacked~false~metrics~(~(~'CWAgent~'backup_time~'host~'desktop~'metric_type~'timing))~region~'us-east-1);query=~'*7bCWAgent*2chost*2cmetric_type*7d
>
> and this description: "metrics".
>
> To do it, I followed these steps:
>
> 1. run `emacs -Q test.org`, where test.org is not an existing file
> 2. emacs GUI displays, type `M-x org-insert-link`
> 3. a "Link" prompt is displayed, paste the link and press return
> 4. a "Description" prompt is displayed, type "metrics" and press return
>
> At this point I expect to see only the text "metrics" in the buffer, with normal
> link decoration (underline and highlight).
>
> Instead, I see "~(~'CWAgent~metrics" with some mix of link decoration
> and some other style, as shown in the following image:
>
> https://i.imgur.com/vb9vE43.png
>
> The actual text from the file is
>
> [[https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2:graph=~(view~'timeSeries~stacked~false~metrics~(~(~'CWAgent~'backup_time~'host~'desktop~'metric_type~'timing))~region~'us-east-1);query=~'*7bCWAgent*2chost*2cmetric_type*7d][metrics]]
>
> This is emacs 27.1 from http://ppa.launchpad.net/kelleyk/emacs/ubuntu,
> with org version 9.3.
>
> Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.22.30, cairo version 1.15.10)
> of 2020-09-19
> Package: Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)
>
> current state:
> ==============
> (setq
> org-src-mode-hook '(org-src-babel-configure-edit-buffer
> org-src-mode-configure-edit-buffer)
> org-link-shell-confirm-function 'yes-or-no-p
> org-metadown-hook '(org-babel-pop-to-session-maybe)
> org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
> org-mode-hook '(#[0 "\300\301\302\303\304$\207"
> [add-hook change-major-mode-hook org-show-all append local]
> 5]
> #[0 "\300\301\302\303\304$\207"
> [add-hook change-major-mode-hook org-babel-show-result-all
> append local]
> 5]
> org-babel-result-hide-spec org-babel-hide-all-hashes)
> org-archive-hook '(org-attach-archive-delete-maybe)
> org-confirm-elisp-link-function 'yes-or-no-p
> org-agenda-before-write-hook '(org-agenda-add-entry-text)
> org-metaup-hook '(org-babel-load-in-session-maybe)
> org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
> "\n\n(fn ENTRY)"]
> org-babel-pre-tangle-hook '(save-buffer)
> org-tab-first-hook '(org-babel-hide-result-toggle-maybe
> org-babel-header-arg-expand)
> org-occur-hook '(org-first-headline-recenter)
> org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
> org-optimize-window-after-visibility-change)
> org-speed-command-hook '(org-speed-command-activate
> org-babel-speed-command-activate)
> org-confirm-shell-link-function 'yes-or-no-p
> org-link-parameters '(("attachment" :follow org-attach-open-link :export
> org-attach-export-link :complete
> org-attach-complete-link)
> ("id" :follow org-id-open)
> ("eww" :follow eww :store org-eww-store-link)
> ("rmail" :follow org-rmail-open :store
> org-rmail-store-link)
> ("mhe" :follow org-mhe-open :store org-mhe-store-link)
> ("irc" :follow org-irc-visit :store org-irc-store-link
> :export org-irc-export)
> ("info" :follow org-info-open :export org-info-export
> :store org-info-store-link)
> ("gnus" :follow org-gnus-open :store
> org-gnus-store-link)
> ("docview" :follow org-docview-open :export
> org-docview-export :store org-docview-store-link)
> ("bibtex" :follow org-bibtex-open :store
> org-bibtex-store-link)
> ("bbdb" :follow org-bbdb-open :export org-bbdb-export
> :complete org-bbdb-complete-link :store
> org-bbdb-store-link)
> ("w3m" :store org-w3m-store-link) ("file+sys")
> ("file+emacs") ("shell" :follow org-link--open-shell)
> ("news" :follow
> #[257 "\301\300\302 Q!\207" ["news" browse-url ":"] 5
> "\n\n(fn URL)"]
> )
> ("mailto" :follow
> #[257 "\301\300\302 Q!\207" ["mailto" browse-url ":"]
> 5 "\n\n(fn URL)"]
> )
> ("https" :follow
> #[257 "\301\300\302 Q!\207" ["https" browse-url ":"]
> 5 "\n\n(fn URL)"]
> )
> ("http" :follow
> #[257 "\301\300\302 Q!\207" ["http" browse-url ":"] 5
> "\n\n(fn URL)"]
> )
> ("ftp" :follow
> #[257 "\301\300\302 Q!\207" ["ftp" browse-url ":"] 5
> "\n\n(fn URL)"]
> )
> ("help" :follow org-link--open-help)
> ("file" :complete org-link-complete-file)
> ("elisp" :follow org-link--open-elisp)
> ("doi" :follow org-link--open-doi))
> org-link-elisp-confirm-function 'yes-or-no-p
> )
>
^ permalink raw reply [relevance 10%]
* Re: A way to avoid unwanted new lines when using paragraph quotes?
@ 2020-12-27 13:55 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-27 13:55 UTC (permalink / raw)
To: Kashyap Chamarthy; +Cc: orgmode
Hello,
Kashyap Chamarthy <kashyap.cv@gmail.com> writes:
> Is there a way to avoid the said new lines in the above mentioned
> examples? (NB: A space right _before_ the quote starts is okay.) Or
> alternatively, is there a way to consistently force a new line in the
> HTML export, after each of "Test 1", "Test 2", et al?
A solution could be to 'force' a homogeneous space between all the items
of the list by modifying the 'margin' property
(https://www.w3schools.com/cssref/pr_margin.asp).
For example:
#+HTML_HEAD: <style> li{margin: 15px;}</style>
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: *strong* markup not honored at boundary of macro input during HTML export
[not found] ` <7e5e7cbe-31d6-2d9e-e450-9c1b54dba95e@gmail.com>
@ 2020-12-23 16:05 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-23 16:05 UTC (permalink / raw)
To: m27315; +Cc: orgmode
You're welcome. Some time ago I had a similar problem with a LaTeX
command with arguments that I wanted to include in a macro. Since the
character U+200b is a kind of "ghost space", it can act as an "invisible
barrier" between the emphasis marks and the characters that precede or
follow them. An emergency cure ;-)
Regards,
Juan Manuel
m27315 <m27315@gmail.com> writes:
> Worked like a charm. Thanks, Juan!
>
> On 2020-12-23 9:22 AM, Juan Manuel Macías wrote:
>> quote (eval (concat "@@html:<span class=\"quote\">“@@" "\u200B" $1 "\u200B" "@@html:”</span>@@"))
>
^ permalink raw reply [relevance 10%]
* Re: *strong* markup not honored at boundary of macro input during HTML export
@ 2020-12-23 15:22 10% ` Juan Manuel Macías
[not found] ` <7e5e7cbe-31d6-2d9e-e450-9c1b54dba95e@gmail.com>
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2020-12-23 15:22 UTC (permalink / raw)
To: m27315; +Cc: orgmode
Hello, a possible dirty solution could be defining the macro with two
Unicode zero-width spaces (u+200b):
#+MACRO: quote (eval (concat "@@html:<span class=\"quote\">“@@" "\u200B" $1 "\u200B" "@@html:”</span>@@"))
Regards,
Juan Manuel
m27315 <m27315@gmail.com> writes:
> Resending as plain-text ... If somebody could point me in the direction of
> the code that might be responsible for this, I'll try to take a look.
>
> ....
>
> If the following org file is exported as HTML, any *strong* markup for words
> at the beginning or the end of the input string are ignored. (I have
> included several slight variations to help testing.)
>
> #+TITLE: Test MACRO with *strong* Markup Input
> #+OPTIONS: date:nil timestamp:nil num:nil stat:t title:t toc:nil
>
> #+MACRO: quote @@html:<span class="quote">“@@$1@@html:”</span>@@
>
> * Test macro with non-marked text:
> Demonstrating that, {{{quote(This is a vanilla quote without markup)}}},
> Abraham Lincoln.
>
> {{{quote(This is a similar control quote without markup)}}}, George
> Washington said.
>
> * Test macro with leading *strongly* marked text:
> Wilson quipped, {{{quote(*Not all* quotes are important!)}}}.
>
> {{{quote(*But this* is a very important quote)}}}, Thomas Jefferson replied.
>
> * Test macro with trailing *strongly* marked text:
> Retorted Yoda, {{{quote(Critical if not uncertain\, all *my quotes are*)}}}.
>
> {{{quote(I am certain they are *all uncertain*)}}}, Anakin sneered.
>
> * Test macro with leading, middle, and trailing marked text:
> Darth Vader threatened, {{{quote(*All* of *my quotes* are *heeded
> carefully!*)}}}.
>
> {{{quote(*Nobody* listens to *meesa* quotes. *Why?*)}}}, Jar-Jar whined.
>
> The condensed filtered HTML output is:
>
> ...
> <h2 id="org40a1103">Test macro with non-marked text:</h2>
> <p>Demonstrating that, <span class="quote">“This is a vanilla
> quote without markup”</span>, Abraham Lincoln.</p>
> <p><span class="quote">“This is a similar control quote without
> markup”</span>, George Washington said.</p>
>
> <h2 id="org962a914">Test macro with leading <b>strongly</b> marked
> text:</h2>
> <p>Wilson quipped, <span class="quote">“*Not all* quotes are
> important!”</span>.</p>
> <p><span class="quote">“*But this* is a very important
> quote”</span>, Thomas Jefferson replied.</p>
>
> <h2 id="org47bf84f">Test macro with trailing <b>strongly</b> marked
> text:</h2>
> <p>Retorted Yoda, <span class="quote">“Critical if not uncertain,
> all *my quotes are*”</span>.</p>
> <p><span class="quote">“I am certain they are *all
> uncertain*”</span>, Anakin sneered.</p>
>
> <h2 id="org08c1694">Test macro with leading, middle, and trailing marked
> text:</h2>
> <p>Darth Vader threatened, <span class="quote">“*All* of <b>my
> quotes</b> are *heeded carefully!*”</span>.</p>
> <p><span class="quote">“*Nobody* listens to <b>meesa</b> quotes.
> *Why?*”</span>, Jar-Jar whined.</p>
> ...
>
> Notice how the *strong* marks are only transformed into <b></b> tags inside
> a string, not at the boundaries.
>
> Can anybody confirm or explain what I am doing wrong?
>
> Thanks!
>
> Trevor
>
>
^ permalink raw reply [relevance 10%]
* Re: Bug: Footnotes on Headers and LaTeX export [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
@ 2020-12-09 15:06 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-09 15:06 UTC (permalink / raw)
To: Charis Michelakis; +Cc: orgmode
Hello,
Charis Michelakis <ch.p.mxs@gmail.com> writes:
> There is a potential bug regarging how footnotes on headers are
> converted to LaTeX.
>
> Consider the following org file:
> ------start-of-file-----------
>
> #+AUTHOR: Me
> #+LATEX_HEADER: \usepackage{titlesec}
>
> * Header1[fn:1]
>
> * Footnotes
>
> [fn:1]Lorem ipsum
It is a LaTeX problem, as the footnote command is a 'fragile' command and should not
be put in a section. Try this:
* Header1[fn:1]
:PROPERTIES:
:ALT_TITLE: Header1
:END:
* Footnotes
[fn:1]Lorem ipsum
in latex it is exported as
\section[Header1]{Header1\footnote{Lorem ipsum}}
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Footnote definition within a verse block has spurious line breaks when exported to LaTeX
@ 2020-12-05 13:47 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-05 13:47 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hello,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> This is hopefully fixed in master branch. Let me knows if it works for
> you.
Thank you, Nicolas. I've tried it and it works perfectly. I see that
\footnotemark\footnotetext is used now, same as in tables. I
think it's a great solution.
Best,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Fallback fonts in LaTeX export for non latin scripts
@ 2023-08-30 8:25 10% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-30 8:25 UTC (permalink / raw)
To: orgmode
The Unicode TeX engines, LuaTeX and XeTeX, have certain features to
apply fonts to scripts (Greek, Cyrillic, Arabic, etc.), without the need
to switch fonts explicitly. But LaTeX does not include any functionality
for loading 'fallback fonts' out of the box. Seeing things from TeX and
LaTeX this is understandable: since LaTeX is a typographic tool, the
user has the responsibility of choosing the fonts and knowing which
fonts to use. But from the Org side things may look different, as the
average user (who may not be interested in typographical or font
complexities) is looking for immediate readability of their texts when
exporting to any format. We know that, when exporting to LaTeX, this
does not always happen, if texts include non-Latin scripts.
These days I'm working on some experimental code to try to provide Org
with some sort of fallbacks fonts on LaTeX export. The functionality
would (for now) be linked to LuaTeX + babel package, since XeTeX,
although it has the ucharclasses package, is more limited.
The idea is to start from a defcustom that is an alist where each element
has the structure (script font). There would also be a default script +
font, for example ("latin" "Linux Libertine"). At the moment it would
only work for the default roman font, but it can be extended to default
sans serif, mono, etc.
The functionality would not be activated by default. When activated, it
also enables LuaTeX as the default LaTeX engine, and on each export a
list of non-latin scripts in the buffer is extracted. Perhaps with
some code like this, which checks for any non-latin characters:
(let ((scripts))
(save-excursion
(goto-char (point-min))
(while
(re-search-forward "\\([^\u0000-\u007F\u0080-\u00FF\u0100-\u017F]\\)" nil t)
(let ((script (aref char-script-table
(string-to-char (match-string 1)))))
(add-to-list 'scripts script)
(setq script-list scripts))))
script-list)
?
Once the list has been extracted, an ad hoc preamble would be formatted
assigning each script the chosen font.
WDYT? Do you think this would be a viable path? I think that in a few
days I can offer something usable for discussion.
Best regards,
Juan Manuel
--
Juan Manuel Macías
^ permalink raw reply [relevance 10%]
* 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
0 siblings, 0 replies; 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: smallcaps: Re: Experimental public branch for inline special blocks
@ 2024-03-05 17:28 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-05 17:28 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin <manikulin@gmail.com> escribió:
> If some type is used through the document multiple times then it is
> better to avoid style="font-variant:small-caps" and use a CSS class
> instead. Even for LaTeX it may be better to define a dedicated command
> to be closer to semantic markup.
>
> Moreover different decorations may be used in LaTeX and HTML. Some type
> may be typed in small caps in LaTeX, but in HTML it may use regular font
> and some color.
The "global attribute" concept implies that there should be (ideally)
the same result in all possible backends (naturally, if the output is
plain text, :color doesn't make much sense). Global attributes are a
quick and easy (for the user) way to create direct formatting, analogous
to the LaTeX commands \textcolor, \textsc, etc. Its casual use is the
most recommended, in my opinion. Let's imagine that a user wants to
color segments of text, in the same color, for LaTeX and odt, and does
not want to bother with predefined styles or macros in odt and LaTeX
respectively.
If a segment of text must have a different appearance, for example, in
LaTeX (small caps) and HTML (red color), you can put:
&_[:html style="color:red;" :prelatex \scshape{}]{text}
And if one wants to have more robust control, for example because many
text segments must have a certain treatment in HTML, odt or LaTeX,
styles, classes and macros can always be defined in the output format.
Additionally, there are the :odt-style, :latex-command, :html-tag and
:html-class attributes to override what is necessary. What's more, in
specific cases global attributes can be added.
I think that the current implementation is very flexible and gives rise
to many possible variations, and the combination of direct formatting
and styles to suit the user.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 10%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-14 18:17 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-14 18:17 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode, Ihor Radchenko
Juan Manuel Macías writes:
> In any case, I personally think that org-latex-language-alist, as it is
> now in this patch, is sufficient.
By the way, Maxim. I have been doing some tests with pdfLaTeX. I've
known for a while now that it's no longer necessary to load the inputenc
package. But it seems that it is not even necessary to load fontenc with
the encoding of each language. Try compiling this:
#+begin_src latex
\documentclass{article}
\usepackage[russian,polutonikogreek]{babel}
\begin{document}
\today
Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲν Ἀρταξέρξης, νεώτερος δὲ
Κῦρος· ἐπεὶ δὲ ἠσθένει Δαρεῖος καὶ ὑπώπτευε τελευτὴν τοῦ βίου, ἐβούλετο τὼ παῖδε ἀμφοτέρω
παρεῖναι.
\selectlanguage{russian}
\today
Emacs написан на двух языках: C и Emacs Lisp (Elisp, диалект Лиспа). При этом сам редактор
является интерпретатором Elisp. По сути дела, большая часть Emacs написана на языке Elisp,
и её можно рассматривать как расширение к основной программе.
\end{document}
#+end_src
In TeX live 2022 the compilation is correct (I think). It seems that
Babel (or russian/greek.ldf) loads the font encodings according to the
declared languages. From the log:
#+begin_src sh
(/usr/share/texmf-dist/tex/latex/cyrillic/t2aenc.def
(/usr/share/texmf-dist/tex/latex/base/t2aenc.dfu)))
(/usr/share/texmf-dist/tex/generic/babel-greek/greek.ldf
(/usr/share/texmf-dist/tex/latex/greek-fontenc/lgrenc.def
(/usr/share/texmf-dist/tex/latex/greek-inputenc/lgrenc.dfu)
(/usr/share/texmf-dist/tex/latex/greek-fontenc/greek-fontenc.def))))
(/usr/share/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def) (./fontenc.aux
(/usr/share/texmf-dist/tex/generic/babel/locale/es/babel-spanish.tex)
(/usr/share/texmf-dist/tex/latex/cbfonts-fd/lgrcmr.fd))
(/usr/share/texmf-dist/tex/latex/cyrillic/t2acmr.fd) [1{/var/lib/texmf/fonts/ma
p/pdftex/updmap/pdftex.map}] (./fontenc.aux) ){/usr/share/texmf-dist/fonts/enc/
dvips/cm-super/cm-super-t2a.enc}</usr/share/texmf-dist/fonts/type1/public/cbfon
ts/grmn1000.pfb></usr/share/texmf-dist/fonts/type1/public/cm-super/sfrm1000.pfb
#+end_src
Is this normal or is it a new Babel feature? If it is a new feature, I
can't find it anywhere in the documentation.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [Tip] Popup-menu with several actions for a link
@ 2023-08-18 18:27 10% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-18 18:27 UTC (permalink / raw)
To: orgmode
Hi,
I’ve been experimenting for a while with the popup.el library
(<https://github.com/auto-complete/popup-el>), which offers an easy way
to create popup menus (even cascading menus), with auto-completion
functions. I’m sharing here a popup menu that I’ve defined to perform
various actions on an Org link, in case anyone finds it useful.
In this list I store the functions that I am writing to manipulate links
(open the link with eww, open the file with an external application,
attach it to an email, upload it to Imgur, copy it to another directory
or move it, visit the file directory, etc.). Something like this:
┌────
│ (setq my-org-link-actions-list
│ '(("Action 1" . function1)
│ ("Action 2" . function2)
│ ("etc..." . etc)))
└────
Then, I have defined this popup-menu that is displayed on a link:
┌────
│ (defun my-org-actions-link-popup ()
│ (interactive)
│ (funcall
│ (popup-menu*
│ (mapcar
│ (lambda (x)
│ (popup-make-item (car x) :value (cdr x)))
│ my-org-link-actions-list)
│ :isearch t)))
└────
And a little addendum. Being a Hyperbole user, it occurred to me a while
ago that a ’secondary action key’ could be very useful to me in certain
contexts. So I defined this:
┌────
│ (defvar my-hyp-alt-act nil)
│
│ (defun my-hyp-action-key-alt ()
│ (interactive)
│ (let ((my-hyp-alt-act t))
│ (action-key)))
└────
If `C-c i' is for the ’primary’ action key, `C-c I' is for the
’secondary’ action:
┌────
│ (global-set-key (kbd "C-c I") #'mi-hyp-action-key-alt)
└────
And then I’ve modified hyperbole `org-link' a bit:
┌────
│ (defact org-link (&optional link)
│ "Follows an optional Org mode LINK to its target.
│ If LINK is nil, follows any link at point. Otherwise, triggers an error."
│ (if (not my-hyp-alt-act)
│ (if (stringp link)
│ (org-link-open-from-string link)
│ (org-open-at-point))
│ (hact #'my-org-actions-link-popup)))
└────
In this way, if I have the point over the link and press `C-c i', the
link opens. If I press `C-c I' the popup-menu is displayed.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [proof of concept] inline language blocks
@ 2024-02-21 12:53 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-21 12:53 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Ihor Radchenko writes:
>>> This is a good idea, although it would be better to make this new markup
>>> element within the framework of more general inline special block we
>>> discussed in the past: https://list.orgmode.org/orgmode/87a6b8pbhg.fsf@posteo.net/
>>
>> Fun fact: the local branch is called inline-special-block, because I
>> originally had that idea in mind when I created it. Then, halfway
>> through, I doubted whether it wouldn't be better to have a specific
>> inline language selector, whose use would be as direct as an emphasis
>> mark. So in the branch there is also a "proto"-inline-special-block with
>> similar syntax: &foo{}.
>>
>> I opted for the -language-block version because, as I said, its use is
>> very 'direct' and covers a common need to segment multilingual text
>> within the paragraph.
>
> My main point is that we should use the same syntax with inline special
> blocks. Similar to how #+begin_verse uses the same syntax as special
> blocks.
>
> We need to finalize inline special block syntax first, and then talk
> about special cases like inline language markup you propose.
As I already said, in my local branch I have both elements created,
based on the same syntax:
- language block: :lang{text}
- special block &type{text}
the latter would be exported, for example, to html as <span class="type">text</span> or to LaTeX as \type{text}
I like the syntax because it is minimalist and not verbose at all. That
could serve as a basis (at least it is good to have a starting point,
because otherwise everything will be diluted in discussions). Then we
can start thinking about whether to add options and how to add them.
>> I think at the time we also discussed whether or not it would be a good
>> idea to provide the inline special blocks with options and attributes,
>> like their older brothers. And how to do it. My biggest concern here is
>> the (let's say) latexification of the paragraph. I mean, one of the
>> great things about Org versus heavier markup like LaTeX is that when org
>> wants to be verbose it uses dedicated lines, but usually keeps the
>> paragraphs clean and readable. I think that any element inside the
>> paragraph should tend to be as "transparent" as simple emphasis marks.
>>
>> I remember that there was also discussion about puting the options
>> outside the paragraph, using some type of identifier. It doesn't seem
>> like a bad idea to me, but I think it adds an extra complication for the
>> user. It would be very tedious for me to write like this (even more
>> tedious than writing in LaTeX).
>
> I still believe that we should /allow/ options inside inline block-type
> markup. This is often necessary in practice. For example, I recommend
> studying
> https://en.wikipedia.org/wiki/Help:Wikitext#Templates_and_transcluding_pages
> and how they had to use ugly |... extensions to provide options.
>
> But it does not mean that users /have to/ use these options. In fact, we
> might design the inline language blocks to ignore options.
The wiki language is for a specific purpose, and I wouldn't consider it
a lightweight markup language, although it is certainly less thick than
html.
Actually I'm just expressing my concerns and doubts, I'm not objecting
to anything. I remember reading in the pandoc issues, a long time ago,
similar discussions every time they talked about extending the markup. I
don't know if it's a good idea to stick to a certain point to preserve
the nature of a lightweight markup language and accept certain intrinsic
limitations instead of providing options that probably have very little
use or can be resolved by some export filter. I don't have a definite
opinion, I'm just raising my doubts. Although I really value simplicity
and minimalism.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 10%]
* [tip] Export some footnotes as pdf annotations (LaTeX) or comments (odt)
@ 2021-10-22 15:01 10% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-22 15:01 UTC (permalink / raw)
To: orgmode
Hi,
Sometimes I need to export an Org document with certain "meta-comments",
so I wrote this export filter to export those footnotes that start with
the string "!annot" to:
- [LaTeX] PDF annotations (requires the pdfcomment LaTeX package),
- [odt] Comments.
#+BIND: org-export-filter-footnote-reference-functions (my-custom-filters/export-footnote-as-annotation)
#+begin_src emacs-lisp :exports results :results none
(defun my-custom-filters/export-footnote-as-annotation (text backend info)
(interactive)
(cond ((and (org-export-derived-backend-p backend 'latex)
(string-match-p "!annot" text))
(replace-regexp-in-string "\\\\footnote{\s*!annot\s*"
"\\\\pdfcomment[icon=Note,opacity=0.4,color=gray,date]{"
text))
((and (org-export-derived-backend-p backend 'odt)
(string-match-p "!annot" text))
(with-temp-buffer
(insert text)
(let* ((from (save-excursion
(goto-char (point-min))
(re-search-forward "!annot" nil t)
(point)))
(to (save-excursion
(goto-char from)
(re-search-forward "</text:p>" nil t)
(- (point) 9)))
(contents (buffer-substring-no-properties from to)))
(delete-region (point-min) (point-max))
(insert (concat
"<office:annotation loext:resolved=\"false\"><dc:creator>"
(car (plist-get info :author))
"</dc:creator><dc:date>"
;; date in iso format
(org-odt--format-timestamp (plist-get info :date) nil t)
"</dc:date><text:p text:style-name=\"P5\"><text:span text:style-name=\"T1\">"
contents
"</text:span></text:p></office:annotation> "))
(setq text (buffer-string)))))))
#+end_src
Example:
Lorem[fn:1] ipsum dolor sit amet,
[fn:1] !annot This note will be exported as an annotation...
And this other filter does not export the notes that start with the
string "!noannot" (although it could be merged with the previous
filter):
#+BIND: org-export-filter-footnote-reference-functions (my-custom-filters/disable-footnote-as-annotation)
#+begin_src emacs-lisp :exports results :results none
(defun my-custom-filters/disable-footnote-as-annotation (text backend info)
(interactive)
(cond ((and (org-export-derived-backend-p backend 'latex)
(string-match-p "!noannot" text))
(replace-regexp-in-string ".+"
""
text))
((and (org-export-derived-backend-p backend 'odt)
(string-match-p "!noannot" text))
(replace-regexp-in-string ".+"
""
text))))
#+end_src
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías --
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 10%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
@ 2022-09-21 14:43 10% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-21 14:43 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> It may produce unexpected results if "Section" heading is demoted all
> the way to paragraph.
If Section heading is demoted all the way to paragraph, I assume that
the expected will happen: that in the output to LaTeX a string will be
added before \paragraph and another string after the content of
\paragraph, which is perfectly consistent with the behavior of these two
properties. It is not that I intend to insist on a discussion; I just
don't quite understand what you mean. Note that these properties are for
LaTeX fine-tuning, and the user is expected to know what he/she wants
and where he/she wants it. If a user wants the arbitrary LaTeX code
before a certain header to be exported as a section (because, for
example, he/she has defined a command in LaTeX that changes the style of
the next \section), you would expect to put those properties in a
"\section" heading.
> Also, :presec/:postsec property names are
> confusing --- it is unclear if they are specific to LaTeX. (when about,
> say, Beamer)
Yes, I agree with that, and I had already commented on it in my previous
message, based on what Maxim had pointed out before, that the names I
had chosen were too imprecise. I like part of what you propose below:
`:attr_latex: :prepend'.
>>> However, I do agree that per-heading control over latex export is
>>> currently cumbersome.
>>>
>>> The canonical ox-latex approach to customize headline export is
>>> org-latex-classes variable. This variable defines (among other things)
>>> pre/post commands during headline export:
>>
>> Apologies in advance if I misunderstood what you're suggesting, but
>> isn't the "org-latex-classes" property supposed to affect the structure
>> of the entire document? What I'm proposing here is rather something
>> specific to particular headings (and its entire content), like the
>> ":ALT_TITLE:" property. If I understand correctly, what you are
>> suggesting is that org-latex-classes can have "local values" for
>> specific headings, if such headings are 'marked' with some property?
>
> Yes, org-latex-classes is controlling the entire document. What I am
> proposing (as an alternative) is subtree-level equivalent of
> org-latex-classes that is also close to org-latex-classes semantics.
>
> More concretely, I mean something like
>
> * Section
> :PROPERTIES:
> :attr_latex: :prepend "section" \setcounter{secnumdepth}{0}
> :attr_latex+: :prepend "section" \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
> :attr_latex+: :append "section" \setcounter{secnumdepth}{2}
> :attr_latex+: :append "section" \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
> :END:
>
> I suggest to use more canonical attr_latex that explicitly limits the
> export backend.
I see. But in any case, something like `:prepend "section"' would be
unnecessary (and even counterproductive) for what I'm proposing, but I'm
afraid I didn't explain myself well in the first message. One of the
benefits of approaching this issue with a few minor modifications to
org-latex-headline is that the result is regardless of the section level
at which the property is applied. We may want to prefix the section with
a specific LaTeX code only for \section (or \paragraph or whatever) and
we may want to introduce a more general LaTeX code, level-agnostic.
Explicitly put "section", "subsection", etc, IMHO unnecessarily
complicates things. But I also insist (as I said at the beginning) that
I don't know if this use case can also be extended to other users.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 17:48 12% ` Juan Manuel Macías
@ 2024-02-10 19:35 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10 19:35 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
Juan Manuel Macías writes:
>> Ihor Radchenko writes:
>> Would it make sense to make :pdf-process work for png previews as well?
>
> It would be ideal. The expected value for org-latex-pdf-process is a
> command or a list of commands, but org-preview-latex-default-process
> expects a plist of various processes and parameters. Maybe with some
> conditional? If only the png extension is provided (without the
> :imagemagick argument), then the expected value is for
> org-preview-latex-default-process. In all other cases, the value is for
> org-latex-pdf-process. The argument could then be called simply
> :process. E.g.:
>
> Assuming the user has somewhere (add-to-list
> org-preview-latex-process-alist my-process):
>
> :results file :file foo.png :process 'my-process [or :process '(a plist)]
>
> In other cases, like this:
>
> :imagemagick yes :results file :file foo.png :process '("lualatex -interaction nonstopmode -output-directory %o %f")
>
> wdyt?
I am attaching a new patch with this idea incorporated. I have also
changed the name from full-to-pdf to standalone.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ob-latex.el-Add-two-new-header-args-to-LaTeX-bl.patch --]
[-- Type: text/x-patch, Size: 2634 bytes --]
From a7f72015007722e665338c39b9a02d675c31cd93 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 10 Feb 2024 02:01:08 +0100
Subject: [PATCH] lisp/ob-latex.el: Add two new header args to LaTeX block.
* (org-babel-execute:latex): `:process' allows modifying the value of
`org-latex-pdf-process' or `org-preview-latex-default-process' in a
specific block. If only the `png' extension is provided (without the
`:imagemagick' argument), then the expected value is for
`org-preview-latex-default-process'. In all other cases, the value is
for `org-latex-pdf-process'. This argument has no effect if the
conversion is to `HTML'. The `:standalone' argument requires that
the LaTeX block contains all the code necessary to be compiled, as if
it were an autonomous LaTeX document: the expected result will always
be a PDF file.
---
lisp/ob-latex.el | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index acb83228b..8bec0c661 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -162,6 +162,14 @@ This function is called by `org-babel-execute-src-block'."
(height (and fit (cdr (assq :pdfheight params))))
(width (and fit (cdr (assq :pdfwidth params))))
(headers (cdr (assq :headers params)))
+ (process (cdr (assq :process params)))
+ (org-preview-latex-default-process (if (and process
+ (string-suffix-p ".png" out-file)
+ (not imagemagick))
+ process
+ org-preview-latex-default-process))
+ (org-latex-pdf-process (if process process org-latex-pdf-process))
+ (standalone (cdr (assq :standalone params)))
(in-buffer (not (string= "no" (cdr (assq :buffer params)))))
(org-latex-packages-alist
(append (cdr (assq :packages params)) org-latex-packages-alist)))
@@ -187,6 +195,14 @@ This function is called by `org-babel-execute-src-block'."
(list org-babel-latex-pdf-svg-process)
extension err-msg log-buf)))
(rename-file img-out out-file t))))
+ ((and (string= "pdf" extension) standalone)
+ (with-temp-file tex-file
+ (insert body))
+ (when (file-exists-p out-file) (delete-file out-file))
+ (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"))
+ (rename-file tmp-pdf out-file t))))
((string-suffix-p ".tikz" out-file)
(when (file-exists-p out-file) (delete-file out-file))
(with-temp-file out-file
--
2.43.0
^ permalink raw reply related [relevance 10%]
* Re: [patch] Add two new header args to LaTeX block
@ 2024-02-10 23:34 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10 23:34 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> I am attaching a new patch with this idea incorporated. I have also
>> changed the name from full-to-pdf to standalone.
>>
>> + (process (cdr (assq :process params)))
>> + (org-preview-latex-default-process (if (and process
>> + (string-suffix-p ".png" out-file)
>> + (not imagemagick))
>
> Considering that 'imagemagick is one of the variants in
> `org-preview-latex-process-alist', it might be reasonable to allow
> :process imagemagick == :imagemagick yes
I wouldn't equate it. ':imagemagic yes' uses 'org-latex-convert-pdf'.
Instead, «:process 'imagemagick» depends on:
(imagemagick :programs
("latex" "convert")
:description "pdf > png"
:message "you need to install the programs: latex and imagemagick."
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.0 . 1.0)
:latex-compiler ("pdflatex -interaction nonstopmode -output-directory %o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O"))
Also, one may want to put «:imagemagick yes» and compile the PDF
with another compiler or with a custom script:
:imagemagick yes :process '(...)
> Also, it feels incomplete to be able to define latex command for :file
> foo.pdf, but be limited to a pre-defined list of symbols for :file .png.
The ".png" method without ":imagemagick" does not depend on
'org-latex-pdf-process' but on 'org-create-formula-image', and this in turn
depends on the value of 'org-preview-latex-default-process':
...
((and (string-suffix-p ".png" out-file) (not imagemagick))
(let ((org-format-latex-header
(concat org-format-latex-header "\n"
(mapconcat #'identity headers "\n"))))
(org-create-formula-image
body out-file org-format-latex-options in-buffer)))
...
If you put :file foo.png without :imagemagick, and want to control the
process or change the compiler, you can do it with:
:process '(foo :latex-compiler ("some LaTeX command"))
since this syntax is what org-preview-latex-default-process expects.
In all other cases, including :imagemagick, the compilation process
depends on the value of org-latex-pdf-process.
Anyway, I don't understand why that feature option (convert to an image
without :imagemagick method) is limited to .png, when other graphic files are
possible. I can define something like this:
(setq org-preview-latex-default-process
'(my-process
:programs ("lualatex" "convert")
:description "pdf > jpg"
:image-input-type "pdf"
:image-output-type "jpg"
:latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
But if I put :file foo.jpg nothing happens. Maybe that part should be
corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." out-file)?
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 10%]
* Re: Pandoc and nested emhases
@ 2023-10-22 19:15 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-22 19:15 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Sorry for the late reply. I haven't had much time these days to
keep up with the list...
Max Nikulin writes:
> It was long time ago...
>
> 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:
>> #+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
>
> Nesting of the same emphasis style may be achieved with Org parser as well:
>
> (org-export-string-as
> "/lorem /ipsum// /dolor/"
> 'latex t)
> "\\emph{lorem \\emph{ipsum}} \\emph{dolor}
> "
>
> Namely closing markers should be combined. See the recent thread
> Tom Alexander to emacs-orgmode. Inconsistent text markup handling when
> double-nesting markers. Mon, 09 Oct 2023 19:02:18 -0400.
> https://list.orgmode.org/dad964f5-c764-4dd5-9829-ca38e3fbeb0d@app.fastmail.com
Interesting. So it should be understood that in Org syntax this dummy
title would be possible:
/Essays on Homer's /Odyssey//
==>
\emph{Essays on Homer's \emph{Odyssey}}
but not this other one:
/Essays on Homer's /Odyssey/. Part One/
\emph{Essays on Homer's /Odyssey}. Part One/
In any case, as Ihor commented in the thread you link, and as you also
commented in the other old thread of my discovery about Pandoc, this
behavior of Pandoc should be understood as a bug since it does not
respect the Org syntax. Although the previous example leaves me a little
perplexed.
Actually, I think nested emphases of equal category are not that
necessary. In general, putting something like \textbf{lorem
\textbf{ipsum} dolor} in LaTeX doesn't make much sense, because \textbf
is not a switch. It would only make sense with the LaTeX \emph command,
which, contrary to what some may think, is not used to put text in
italics (that's what \textit is for), but to emphasize a text according
to the context: if the context is in normal font, italics; and vice
versa. If I don't miss anything, I think there is nothing similar in
either html or odt/docx.
--
Juan Manuel Macías
^ permalink raw reply [relevance 10%]
* Re: [patch] Add two new header args to LaTeX block
@ 2024-02-18 13:43 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-18 13:43 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> In any case, if the org-create-formula-image method is going to stay, I
>> think it is fine as it is (except for extending the allowed file formats
>> to more extensions, and not only .png). I also believe that the :process
>> argument is sufficient for the user to control the value of
>> org-latex-pdf-process or org-preview-latex-default-process, as
>> appropriate.
>
> My concern about your patch is that it creates even more divergence
> between different branches of code in `org-babel-execute:latex'.
> With the new proposed features only available to some code branches,
> `org-babel-execute:latex' will just become more messy and harder to
> maintain.
>
> I'd prefer to refactor `org-babel-execute:latex' first, before adding
> new header arguments.
org-create-formula-image inserts LaTeX code:
...
(with-temp-file texfile
(insert latex-header)
(insert "\n\\begin{document}\n"
"\\definecolor{fg}{rgb}{" fg "}%\n"
(if bg
(concat "\\definecolor{bg}{rgb}{" bg "}%\n"
"\n\\pagecolor{bg}%\n")
"")
"\n{\\color{fg}\n"
string
"\n}\n"
"\n\\end{document}\n"))
...
that, /in principle/, would make it incompatible with the :standalone
argument (in my patch), which allows writing all LaTeX code from scratch
in the block content.
Anyway, it is true that org-babel-execute:latex has grown in a somewhat
irregular way. For example, I don't quite understand why the simple
output to PDF and the conversion to an image with :imagemagick live in
the same conditional:
(or (string= "pdf" extension) imagemagick)
I would propose three main branches in this function:
- A PDF branch, using org-format-latex-header with its valid options,
and other sub-branches with conversion from the PDF, for example, the
use of :imagemagick. Or you could even think of any possible
conversion process using a hypothetical :pdf-postprocess
- A branch for orf-create-formula-image
- a third branch to export to html, with org-babel-latex-htlatex.
Having three clearly differentiated branches would make the code easier
to maintain.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 10%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
@ 2023-09-08 14:42 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-08 14:42 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Max Nikulin writes:
> I am still unsure that de and de-de should be mapped to different
> babel language configurations.
I think that for practical purposes de and de-de should be treated the
same in both babel and polyglossia. In the new fixed version of
org-babel-language-alist I thought it would be useful to support a list
of languages codes as car for each element, in addition to a simple
string. In such a way:
(("de" "de-de") :babel "ngerman" :babel-ini-alt "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script "latin" :script-tag "latn")
I've had to make some small modifications to
org-latex-guess-babel/polyglossia-language, to get that to work.
:babel-ini-alt refers to an alternative name that is used only if
\babelprovide is present. I'm also adding the :script and :script-tag
properties for each language.
I have done something similar with the case of Chinese Simplified (a new
language that I have added):
(("zh" "zh-cn") :babel-ini-only "chinese" :polyglossia "chinese" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans")
Between today and tomorrow I will try to send the patch. I saw that
org-latex-language-alist had a few typos as well, some inherited from
the previous lists that were merged.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
@ 2023-09-10 21:15 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-10 21:15 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> For context, I plan to provide a global language-identifier alist that
> will link human-readable language names to abbreviations like "de",
> "de-de", etc. These abbreviations are not unique to LaTeX, but also used
> elsewhere, so there is no guarantee that babel .ini files will always
> use a consistent set of language abbreviations.
Is the code you're working on in a public repository, to keep an eye on?
As I mentioned in previous messages, that seems like a great improvement
to me. I think it was not a happy decision at the time to use languages
codes to declare the language of the document in Org. Language codes can
be useful at a low level (although they can also lead to confusion), but
I think that for a user level it is more practical to use human-readable
names, as is done in babel or polyglossia, and in general, any user
interface outside of LaTeX. Although babel also allows language codes as
a value for some \babelprovide options (for example, I can define a new
"virtual" language, importing the Greek captions:
\babelprovide[captions=el]{mylanguage}).
In case it helps you, on page. 19 of the Babel manual there is an
exhaustive list of all the languages codes, and on p. 22 a list of
supported (human readable) language names for loading ini files. The
language names of the old ldf files are on p. 49:
https://CTAN/macros/latex/required/babel/base/babel.pdf
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [DISCUSSION] Re-design of inlinetasks
@ 2023-08-26 11:42 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-26 11:42 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
>> ... They
>> behave like a true section, except that they are not headed by titles or
>> level numbers.
>
> May they contain sub-sections?
I think that would not be expected, since an anonymous section is just a
break in the text that has neither a title nor a section number. There
are many possible scenarios. Let's imagine, for example, that an author
is working on a section of an article. And at the end of various
subsections he/she wants to make some text breaks that, for whatever
reason, don't deserve either a title or a subsubsection number.
Anonymous breaks using asterisks or other symbols is usually the applied
remedy. The advantage of enclosing the content of the anonymous section
in an inlinetask is that we have a 'true' section with content (over
which you have control). That would not happen if the author explicitly
added a break symbol and continue writing.
Anonymous breaks are also widely used in essay or narrative texts. An
essay text, published as a blog entry or as an article, can be perfectly
structured into anonymous sections:
contents 1
***
contents 2
***
etc
See:
https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering
https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks
--
Juan Manuel Macías
^ permalink raw reply [relevance 10%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
@ 2022-09-20 17:18 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-20 17:18 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> I do not like this idea.
> Please remember that headlines may be exported as parts, sections,
> subsections, list items, or paragraphs depending on the headline level.
> Arbitrary pre/post commands may unexpectedly break things during export.
I don't see why, if the user knows LaTeX and knows what he/she is doing.
Sometimes it's just adding an "\addtocontents" just before the
section/subsection,etc. The property that adds the string before and the
property that adds the string after are understood to affect the entire
heading at the current level and its contents, including lower levels.
For example, if someone wants the current heading (and all its
sublevels) not to be included in the TOC but to be included in the
headers of the pages, it would suffice to (I keep here the original name
of the properties that I proposed in the patch, but I think Maxim's
proposed name is more accurate):
-----------------------------------
* Section
:PROPERTIES:
:presec: \setcounter{secnumdepth}{0}
:presec+: \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
:postsec: \setcounter{secnumdepth}{2}
:postsec+: \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
:END:
Lorem ipsum dolor.
** Subsection one
lorem
** Subsection two
ipsum
Which would pass to LaTeX as:
\setcounter{secnumdepth}{0} \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
\section{Section}
Lorem ipsum dolor.
\subsection{Subsection one}
lorem
\subsection{Subsection two}
ipsum
\setcounter{secnumdepth}{2} \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
----------------------------------
(The above can even be simplified from LaTeX by defining a simple
environment, but I've exemplified it like this to make it look better).
In what situations might this return unexpected results?
> However, I do agree that per-heading control over latex export is
> currently cumbersome.
>
> The canonical ox-latex approach to customize headline export is
> org-latex-classes variable. This variable defines (among other things)
> pre/post commands during headline export:
Apologies in advance if I misunderstood what you're suggesting, but
isn't the "org-latex-classes" property supposed to affect the structure
of the entire document? What I'm proposing here is rather something
specific to particular headings (and its entire content), like the
":ALT_TITLE:" property. If I understand correctly, what you are
suggesting is that org-latex-classes can have "local values" for
specific headings, if such headings are 'marked' with some property?
Best regards,
Juan Manuel
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
@ 2023-08-12 11:28 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-12 11:28 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>> + (vwidth (if (not lit)
>> + (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")
>> + ""))
>
> Can just do (if (and versewidth (not lit)) (format ...) "")
>
>> + (linreset (if (not lit)
>> + (if lin "\n\\poemlines{0}" "")
>> + "")))
>
> (if (and lin (not lit)) ...)
Thanks for the suggestions. Yes, it's simpler that way.
>> (concat
>> (org-latex--wrap-label
>> verse-block
>> ;; In a verse environment, add a line break to each newline
>> ;; character and change each white space at beginning of a line
>> - ;; into a space of 1 em. Also change each blank line with
>> - ;; a vertical space of 1 em.
>> - (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
>> + ;; into a normal space, calculated with `\fontdimen2\font'.
>> + ;; One or more blank lines between lines are exported as a
>> + ;; single blank line. If the `:literal' attribute is used,
>> + ;; CONTENTS is exported as is, with no environment, preserving
>> + ;; line breaks and vertical and horizontal spaces.
>> + (format (if (not lit)
>> + "%s\\begin{verse}%s\n%s\\end{verse}%s"
>> + "%s%s\n%s%s")
>
> In the case of lit vwidth and attr are always empty. So, you are
> inserting an extra newline in front. Is it intentional?
I used that procedure because an extra blank line before (in the LaTeX
code) it has no effect in LaTeX compilation. And in case the :literal
attribute is present, vertical spaces are achieved by explicit
\vspace*{}. One or more empty lines before it just marks the beginning
of a new paragraph.
Naturally, if :literal is used the rest of attributes are meaningless
because they are intended for the verse environment. They can even give
some error in the compilation. So I opted to disable them with the mere
presence of :literal, leaving them 'empty' (so as not to manipulate the
function further).
>> + (concat "\\("
>> + (regexp-quote org-latex-line-break-safe)
>> + "\n\\)"
>> + "\\(^[ \t]*"
>> + (regexp-quote org-latex-line-break-safe)
>> + "\n"
>> + "\\)+")
>> + (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
>
> May also use rx for better readability.
I remember that I tried rx a while ago and found it very useful and
comfortable, but then I haven't done anything with it. The fact is that
over time I have ended up getting used to suffering from the classic
regexp and it is hard for me to get out of there :-). Of course, with rx
it would be clearer but I would have to refresh my memory.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
@ 2022-09-25 12:06 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-25 12:06 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>>> #+ATTR_BACKEND: :export_template "can also work on non-headings"
>>> Paragraph.
>>
>> In this case I would not see it necessary, IMHO. For simple things (of
>> the begin/end style) there are the special blocks. And for more complex
>> pre- and/or post- code we have export blocks and export snippets. Since
>> there is no heading involved here, there would be no danger of the
>> pre-code leaving with the content of the previous header.
>
> I do not insist on this. I just see supporting this easier (it will work
> automatically) compared to explicitly limiting :export_template to
> headings/inlinetasks.
>
> Also, some people prefer to have such option (Pedro Andres Aranda
> Gutierrez in off-list reply to
> https://orgmode.org/list/87fsgmyyhw.fsf@localhost)
Well, it's evident that your idea of the export_template attribute is
very productive and can be consistently extended to more situations. One
scenario where I think it would be very useful is also in tables and
figures, but in this case to insert arbitrary code *inside* the table,
figure, etc. environments. This is something that gets asked on the list
from time to time and the solutions provided are usually a bit tricky.
Going back to the earlier :ATTR_BACKEND: issue as a property for
headings, I've been doing some testing and scribbled down a possible
function[1] whose code is almost entirely stolen from
org-export-read-attribute, with some modifications. Evaluated at the
headline, it returns the value of the ATTR_BACKEND property as a plist.
And then that plist could be easily manipulated on each backend to
format export_template conveniently. For example:
* headline
:PROPERTIES:
:ATTR_LaTeX: :export_template \begin{myenv}\n%s\n\end{myenv}
:ATTR_LaTeX+: blah blah blah
:END:
==> (:export_template "\\begin{myenv}\\n%s\\n\\end{myenv} blah blah blah")
I don't know if that would be the way to go...
Best regards,
Juan Manuel
[1]
(defun possible-function (attribute)
"TODO"
(let* ((prepare-value
(lambda (str)
(save-match-data
(cond ((member str '(nil "" "nil")) nil)
((string-match "^\"\\(\"+\\)?\"$" str)
(or (match-string 1 str) ""))
(t str)))))
(attributes
(let ((value (org-entry-get nil attribute)))
(when value
(let ((s value) result)
(while (string-match
"\\(?:^\\|[ \t]+\\)\\(:[-a-zA-Z0-9_]+\\)\\([ \t]+\\|$\\)"
s)
(let ((value (substring s 0 (match-beginning 0))))
(push (funcall prepare-value value) result))
(push (intern (match-string 1 s)) result)
(setq s (substring s (match-end 0))))
;; Ignore any string before first property with `cdr'.
(cdr (nreverse (cons (funcall prepare-value s) result))))))))
attributes))
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: publishing: no default publishing function, or symbol is not defined
@ 2021-06-19 12:48 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-19 12:48 UTC (permalink / raw)
To: Christopher W. Ryan; +Cc: orgmode
Hi Christopher,
Christopher W. Ryan" via "General discussions about Org-mode. writes:
> I'm making my first foray into publishing a project. I'm running GNU
> Emacs 26.2 (build 1, x86_64-w64-mingw32) of 2019-04-13, on Windows 10.
>
> I've defined a single project, just to try it out and learn.
As Christian Moe said, the function you need is
`org-html-publish-to-html'.
In case it helps, I keep this blog about typography and TeX (in spanish),
made with org-publish: https://lunotipia.juanmanuelmacias.com/index.html
The blog's public repository is at:
https://gitlab.com/maciaschain/lunotipia
And this is the org-publish configuration for the blog:
;; lunotipia
("lunotipia-notes"
;; Org files
:base-directory "~/Git/lunotipia/org/"
:base-extension "org"
;; HTML files
:publishing-directory "~/Git/lunotipia/public/"
:publishing-function org-html-publish-to-html
:recursive t
:auto-sitemap t
:sitemap-title "Textos publicados"
:sitemap-function my-sitemap-function-lunotipia
:sitemap-filename "entradas.org"
:sitemap-style list
:sitemap-sort-files anti-chronologically
:exclude "org-rss\\|theindex\\|acerca-de\.org"
:makeindex t
:html-postamble mi-postamble)
;; static files
("lunotipia-static"
:base-directory "~/Git/lunotipia/org/images/"
:base-extension "css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf"
:publishing-directory "~/Git/lunotipia/public/images/"
:recursive t
:publishing-function org-publish-attachment)
And my custom sitemap function:
(defun my-sitemap-function-lunotipia (title list)
"Return sitemap using TITLE and LIST returned by `org-blog-sitemap-format-entry'."
(concat "#+TITLE: " title "\n\n"
"#+SETUPFILE:" "~/Git/lunotipia/html-lunotipia.setup"
"\n#+SETUPFILE:" "~/Git/gnutas/macros-gnutas.setup"
"\n#+AUTHOR:" "Juan Manuel Macías"
"\n#+LANGUAGE:" "es"
"\n#+begin_archive\n"
(mapconcat (lambda (li)
(format "@@html:<li>@@ %s @@html:</li>@@" (car li)))
(seq-filter #'car (cdr list))
"\n")
"\n#+end_archive\n"
"\n#+begin_export html"
"\n<div>"
"\n<hr />"
"\n<p>"
"\n<a href=\"acerca-de.html\">Acerca de...</a>"
"\n</p></div>"
"\n<p>"
"\n<a href=\"https://maciaschain.gitlab.io/lunotipia/rss.xml\">RSS</a>"
"\n</p></div>"
"\n#+end_export\n"))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images export
@ 2024-01-02 21:43 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-02 21:43 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Apologies for my delay in answering all the interesting questions
you raised in this last message. November and December have been
horrible work days for me (all publishers are always in a hurry) and I
haven't been able to attend to the mailing list as I would like...
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> What about :wrap?
>>
>> I like :wrap. What's more, remembering that old thread where
>> some questions about code before/after the image were discussed,
>> what if the expected value of :wrap were a kind of template? This would
>> allow code to be placed before and/or after (not just an environment)
>> the image, always within the float environment, if it exists. Something
>> like this:
>>
>> #+ATTR_LaTeX: :float nil :wrap \begin{minipage}[b]{10pc}\small\n%s\n\end{minipage}
>> #+CAPTION: caption
>> [[file:foo.png]]
>> ...
>> #+ATTR_LaTeX: :float minipage :placement [b]{10pc} :caption \captionof{figure}{caption}
>> [[file:foo.png]]
>>
>> I don't know if it would be appropriate to explain in the Manual that
>> doing so would not be... "correct"? I don't know if there is any term in
>> programming to designate these situations which, without being bugs, are
>> functionalities not consciously sought...
>
> What about making :wrap override :float completely + obsoleting :float.
> We can allow wrap to have special values like in float:
>
> :wrap t/:wrap multicolumn/:wrap sideways
>
> With these special values, :placement will be taken into account.
+1. Great idea.
> Further, we can make templates a bit more detailed.
> Starting from similar to what you proposed in the above
>
> :wrap \begin{minipage}[b]{10pc}\small\n%{body}\n\end{minipage}
>
> to more granular control over caption, centering, comment-include,
> and image-code:
>
> %{caption} %{caption-text} %{centering} %{comment} %{comment-text}
> %{image} %{image-path}.
>
> If the :wrap text does not contain %{...} placeholder, it will be
> treated as what :float artbirary-environment does.
>
> We may even consider something like
>
> #+name: latex-template
> #+begin_src latex :export none
>
> \begin{minipage}[b]{10pc}\small
> %{body}
> \end{minipage}
> #+end_src
>
> #+attr_latex: :wrap latex-template[]
>
> As a bonus, :wrap may allow prepending/appending arbitrary code to
> headings:
>
> * Heading starting at a new page
> :PROPERTIES:
> :ATTR_LATEX: :wrap \clarpage%{default}
> :END:
I really like what you propose, both the idea and the syntax. I think
that such a versatile template system (with such a level of granularity
but with a clear syntax at the same time) would be a killer feature. It
wouldn't be bad to also extend it to the case of tables and other
backends, such as html. I also think it would solve a "classic" Org
syntax issue (in my opinion) which is the difficulty in 'nesting things'.
Well, it can be done currently (for example, the special blocks do their job
pretty well), but at the cost of increasing the verbosity of the code (I am
thinking, for example, of using the LaTeX threeparttable package through
nested special blocks...)
Best regards, and happy New Year
--
Juan Manuel Macías
^ permalink raw reply [relevance 11%]
* A question about local/experimental branches
@ 2024-02-25 13:53 11% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-25 13:53 UTC (permalink / raw)
To: orgmode
Hi,
I've noticed that the code for my implementation of the new
'inline-special-block' experimental element is growing. In addition, I
introduce modifications and improvements daily. So I think it might be a
good idea to make my local branch public, in case someone wants to try
it or contribute to the project.
My question is if there is any set of good practices to do this, or is
it enough to publish the local branch 'as is'.
Currently I have completed, and are perfectly usable, the export to
LaTeX and HTML. I have also improved the syntax. Now, if aliases are
used for group optional attributes, it is not necessary to put :alias
foo, but @foo@. Example:
#+options: inline-special-block-aliases:(("latin" :lang "la" :color blue :prelatex "\\itshape " :html "style=\"font-style:italic;\""))
This is an example of Latin text: &_[@latin@]{lorem ipsum dolor sit amet}.
This is an example of Latin text with small caps: &_[@latin@ :smallcaps t]{lorem ipsum dolor sit amet}.
LaTeX ==>
This is an example of Latin text: {\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit amet}}.
This is an example of Latin text with small caps: {\scshape{}\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit amet}}
HTML ==>
This is an example of Latin text: <span style="color:blue;font-style:italic;" lang="la">lorem ipsum dolor sit amet</span>.
This is an example of Latin text with small caps: <span style="color:blue;font-variant:small-caps;font-style:italic;" lang="la">lorem ipsum dolor sit amet</span>.
Related: https://list.orgmode.org/87ttlyloyr.fsf@posteo.net/
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: [Tip] Popup-menu with several actions for a link
@ 2023-08-19 20:29 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-19 20:29 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> I’ve been experimenting for a while with the popup.el library
>> (<https://github.com/auto-complete/popup-el>), which offers an easy way
>> to create popup menus (even cascading menus), with auto-completion
>> functions. I’m sharing here a popup menu that I’ve defined to perform
>> various actions on an Org link, in case anyone finds it useful.
>
> Since Emacs 28, Emacs has built-in context menu. (terminal is also
> supported) Moreover, major modes are encouraged to add support for
> context menus.
Thanks for the information. Do you mean context-menu-mode? I'll keep an
eye on it. When you say terminal support, do you mean terminal emulators
or TTY? Because I often use Emacs on the linux framebuffer with fbterm,
and popup.el works fine on the tty. Also, I don't usually use the mouse
much (actually I only use it in Gimp and the like) and the combination
of popup.el with hyperbole is more comfortable and keyboard-centric for
me.
>> In this list I store the functions that I am writing to manipulate links
>> (open the link with eww, open the file with an external application,
>> attach it to an email, upload it to Imgur, copy it to another directory
>> or move it, visit the file directory, etc.). Something like this:
>
> May you explain more about how you attach to an email/upload?
Sure! But they are very simple functions, which I don't use much.
Although they work fine for what I want:
The first requires the imgur.el package; the second one needs gnus-dired-mode:
(defun my-org-link-to-ingur ()
(interactive)
(let* ((path (org-element-property :path (org-element-context))))
(imgur-upload-image (expand-file-name path) nil t)))
(defun my-org-link-to-mail-attachment ()
(interactive)
(let* ((path (org-element-property :path (org-element-context))))
(gnus-dired-attach (list (expand-file-name path)))))
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: Create in Org a bilingual book with facing pages
@ 2022-09-27 16:50 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-27 16:50 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi, Ihor, thanks for your comments.
Ihor Radchenko writes:
> This post appears to be a nice fit for
> https://orgmode.org/worg/org-blog-articles.html (except non-permanent
> imgur links). Do you have an Org version? Or maybe an actual blog post?
Precisely I have in mind to publish in my blog on typography
(https://lunotipia.juanmanuelmacias.com/) an extended and more detailed
version of this text, also including the function to which I refer (and
that I have not included in the post to the list for not making the text
any longer). The drawback is that my blog is in Spanish. I can easily
make an English version of the blog post as well. Who should I send the
link to, when I post it?
>> To compile the two PDFs separately and get the PDF in sync, I also do it
>> from Org using a shell source block. So I have all PDFs always
>> synchronized up to date. The synchronized PDF is obtained with pdftk:
>>
>> <https://i.imgur.com/qbSg2po.png>
>
> I notice two things here:
>
> 1. \clearpage command, which reminds me about
> https://orgmode.org/list/87mtamjrft.fsf@localhost
> May it be useful to have page break syntax element in Org?
I really don't have an opinion at the moment... As a user I try to put
as few direct LaTeX commands as possible: commands like \newpage,
\pagebreak, \clearpage, \bigskip, \quad, etc. Whenever I can, I
prefer to control spaces and page breaks using more general macros. And,
when I put these commands, the fact of resorting to an export snippet
does not usually bother me, since they are not very verbose commands.
But I don't know what other users will think...
> 2. You had to use direct LaTeX for caption. Can we do something to make
> the #+caption keywords more useful?
Yes, I use direct LaTeX in that case because I need to put the command
\caption*, the starred version of \caption provided by the caption
package. And before \caption*, I wanted to also add a \captionsetup. For
those cases, I think the :caption attribute already does a good job.
What would be interesting (IMO) is to be able to introduce arbitrary code
within the figure environment through an attribute, but this is where
the possible :export_template attribute could come into play, as we
discussed in the other thread.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX
@ 2022-10-15 21:35 11% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-15 21:35 UTC (permalink / raw)
To: orgmode
The recent addition of the `org-latex-line-break-safe' constant makes it
impossible to compile verse blocks. The reason is that now a \\ is
inserted between each stanza (aka each paragraph), instead of the
`\vspace{1em}' as before. That's wrong, as this compile error message
says:
---------
A \newline or \\ command appears between paragraphs, where it makes no
sense. If you're trying to ``leave a blank line'', use a \vspace
command.
---------
You can test yourself with this example:
#+begin_verse
lorem ipsum dolor
lorem ipsum dolor
lorem ipsum dolor
lorem ipsum dolor
lorem ipsum dolor
lorem ipsum dolor
#+end_verse
On the other hand, I have a few reservations about the usefulness of
org-latex-line-break-safe. To begin with, it is a particular solution
applied in a general way. This can have unexpected consequences, as has
happened in verse blocks. It's like putting your whole body in a
cast because of a broken finger.
I think if the reason for this addition is to prevent problems with
square brackets, in certain contexts, why not just apply a point
solution? For example, putting {[}, which is a common LaTeX way to
protect a square bracket. Use a macro, for example, or even
define a new entity, something like:
(setq org-entities-user
'(("lbrack" "{[}" nil "[" "[" "[" "[")
("rbrack" "{]}" nil "]" "]" "]" "]")))
And finally, I think that applying a general solution to this problem is
something that should be done(IMHO) in LaTeX and not in Org, for
example, with some new package that would protect certain signs or
through ad hoc LaTeX/Lua code.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
@ 2023-09-09 23:59 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-09 23:59 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode, Max Nikulin
Ihor Radchenko writes:
> I am thinking about something like
>
> (let ((de-plist '(...)))
> `(...
> ("de" ,@de-plist)
> ("de-de" ,@de-plist)
> ...))
>
> This is copy-paste-proof and does not require breaking changes in the
> value structure.
I like the idea because it avoids errors, but I don't know if
it's worth it, there being only two cases (at the moment). This other
possibility occurred to me, just to make it easier to read and not have
to navigate to the list of variables:
(let* ((basic-code)
(shared-plist (lambda (&rest plist)
(setq basic-code plist))))
`(...
("de" ,(funcall shared-plist :babel "ngerman" :babel-ini-alt "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script "latin" :script-tag "latn"))
("de-de" ,@basic-code)
...
("zh" ,(funcall shared-plist :babel-ini-only "chinese" :polyglossia "chinese" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans"))
("zh-cn" ,@basic-code)))
Likewise, there being two cases (even in the case of Chinese you could
perfectly omit zh-cn, because it is a new language and there is no
danger of regression), I would say that it is not worth complicating the
code so much.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Link type for pdf-tools annotations
@ 2024-02-08 22:13 11% Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-08 22:13 UTC (permalink / raw)
To: orgmode
Hi,
Many times I need to "save" an annotation point in the pdf-tools
annotations buffer. So I defined a new link type and the function to
store it. The link is stored with the structure:
[[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p. page-number)]]
The link opens the PDF and jumps to the specific annotation. A screenshot:
https://i.imgur.com/hw96NfD.png
I share the code here in case it is useful to someone:
#+begin_src emacs-lisp
(defun my-org-pdf-annot-store-link ()
(when (equal (format "%s" major-mode) "pdf-annot-list-mode")
(let* ((pdf-buf pdf-annot-list-document-buffer)
(pdf-file (buffer-file-name pdf-buf))
(annot (pdf-annot-getannot (tabulated-list-get-id) pdf-buf))
(date (pdf-annot-print-property annot 'modified))
(page (save-excursion
(beginning-of-line)
(re-search-forward "\\(^\s+\\)\\([[:digit:]]+\\)" nil t)
(match-string 2)))
(link (concat "pdf-annot:" pdf-file "::" date))
(desc (format "%s (annot. on p. %s)" (file-name-nondirectory pdf-file) page)))
(org-link-store-props
:type "pdf-annot"
:link link
:description desc))))
(org-link-set-parameters
"pdf-annot"
:follow (lambda (path)
(let ((a (if (string-match "::\\(.+\\)" path)
(match-string 1 path)
(error "no annotation date")))
(file-path (replace-regexp-in-string "::.+" "" path)))
(find-file file-path)
(pdf-annot-list-annotations)
(let ((anot-buf (format "*%s's annots*"
(file-name-sans-extension
(buffer-name)))))
(with-current-buffer anot-buf
(save-excursion
(goto-char (point-min))
(re-search-forward a nil t)
(call-interactively #'pdf-annot-list-display-annotation-from-id))))))
:store #'my-org-pdf-annot-store-link)
#+end_src
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: Line breaks and brackets in LaTeX export
@ 2022-10-17 15:01 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-17 15:01 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Daniel Fleischer, Max Nikulin, emacs-orgmode
Juan Manuel Macías writes:
> So, in the current situation, we can ask ourselves: is
> \empty everywhere safe? Everything points to yes. Can we be 100% sure?
> ...?
I think I've found a case where \empty 'everywhere' can produce unexpected
results. I don't know if I'm missing something, because I've never used
this package, but taking a couple of random examples from the tabularray
documentation, you can see it, compiling the following snippet (by the
way, putting \\[0pt] instead of \\\empty the result is correct). Here in
both cases the problem is in the last \empty:
\documentclass{article}
\usepackage{tabularray}
\begin{document}
\section{Normal}
\begin{tblr}{lccr}
\hline
Alpha & Beta & Gamma & Delta \\
\hline
Epsilon & Zeta & Eta & Theta \\
\hline
Iota & Kappa & Lambda & Mu\\
\hline
\end{tblr}
\section{With `empty'}
\begin{tblr}{lccr}
\hline
Alpha & Beta & Gamma & Delta \\\empty
\hline
Epsilon & Zeta & Eta & Theta \\\empty
\hline
Iota & Kappa & Lambda & Mu\\\empty
\hline
\end{tblr}
\section{Normal}
\begin{tblr}[m]{hlines}
Alpha & Beta & Gamma \\
Epsilon & Zeta & Eta\\
Iota & Kappa & Lambda\\
\end{tblr}
\section{With `empty'}
\begin{tblr}[m]{hlines}
Alpha & Beta & Gamma \\\empty
Epsilon & Zeta & Eta\\\empty
Iota & Kappa & Lambda \\\empty
\end{tblr}
^ permalink raw reply [relevance 11%]
* Re: [patch] ox.latex.el: Add missing character warnings
@ 2024-02-13 16:01 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-13 16:01 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]
Ihor Radchenko writes:
> Probably something to do with my Texlive technically having Chinese
> support.
>
> I am getting
>
> ! Package inputenc Error: Unicode character 你 (U+4F60)
> (inputenc) not set up for use with LaTeX.
>
> See the inputenc package documentation for explanation.
> Type H <return> for immediate help.
> ...
>
> l.28 Hello. 你
> 好.
>
> ! Package inputenc Error: Unicode character 好 (U+597D)
> (inputenc) not set up for use with LaTeX.
>
> See the inputenc package documentation for explanation.
> Type H <return> for immediate help.
> ...
>
> l.28 Hello. 你好
I have fixed the org-latex-known-warnings regexp in the attached patch.
I think it should work fine now...
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Add-missing-character-warnings.patch --]
[-- Type: text/x-patch, Size: 1816 bytes --]
From 742d67f2e8d4f1896d89f7543948facd65687ffe Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 13 Feb 2024 16:56:23 +0100
Subject: [PATCH] lisp/ox-latex.el: Add missing character warnings
* (org-latex-known-warnings): Two missing character warnings are
added: one for LuaLaTeX/XelaTeX and another for pdfLaTeX.
---
lisp/ox-latex.el | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..2fdc2afe8 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1511,6 +1511,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'."
("Underfull \\hbox" . "[underfull hbox]")
("Overfull \\hbox" . "[overfull hbox]")
("Citation.*?undefined" . "[undefined citation]")
+ ("^!.+Unicode character" . "[unicode character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]")
+ ("Missing character: There is no" . "[Missing character(s): please load an appropriate font with the fontspec package]")
("Undefined control sequence" . "[undefined control sequence]"))
"Alist of regular expressions and associated messages for the user.
The regular expressions are used to find possible warnings in the
@@ -4435,7 +4437,11 @@ encountered or nil if there was none."
(save-excursion
(goto-char (point-max))
(when (re-search-backward "^[ \t]*This is .*?TeX.*?Version" nil t)
- (if (re-search-forward "^!" nil t) 'error
+ (if (and
+ (re-search-forward "^!\\(.+\\)" nil t)
+ ;; This error is passed as missing character warning
+ (not (string-match-p "Unicode character" (match-string 1))))
+ 'error
(let ((case-fold-search t)
(warnings ""))
(dolist (warning org-latex-known-warnings)
--
2.43.1
^ permalink raw reply related [relevance 11%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
@ 2023-10-04 14:34 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-04 14:34 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Further, we also provide :environment and :options attributes that do
> the same thing, but without special treatment of standard
> t/multicolumn/wrap/sideways/nil values in :float.
t/multicolumn/wrap/sideways/nil... and any arbitrary value (see lines 14125
and 14262 in org-manual.org).
>>> What we might do it to introduce something like a new :wrap attribute:
>>>
>>> #+attr_latex: :wrap subfigure,{\textwidht}
>
> So, it might be even better idea to extend :environment/:options
> attributes to more elements - their names make more sense and the values
> do not have a pre-defined special meanings.
Currently it is not possible in inline images (if I don't miss anything) this:
#+ATTR_LaTeX: :environment minipage :options {\textwidth}
[[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
Implementing :environment/:options here would result in redundancy with:
#+ATTR_LaTeX: :float minipage :placement {\textwidth}
[[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
which produces the same.
In tables there is more consistency because :float is a float
environment (table or any arbitrary value) and :environment is a table
environment (tabular or any arbitrary value). Here :placement :options
and :align act as what is expected of them:
#+ATTR_LaTeX: :environment foo :float var :placement [!h] :options [blah] :align cccc
|a|a|a|a|
===>
\begin{var}[!h]
\centering
\begin{foo}[blah]{cccc}
a & a & a & a\\[0pt]
\end{foo}
\end{var}
\end{document}
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
@ 2024-03-12 13:45 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-12 13:45 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Max Nikulin, Stefan Nobis
In the last commit I have introduced some changes. Now this new feature
is no longer hardcoded in each backend but is controlled by an external
function in ox.el. I think this can simplify the implementation for
other backends.
As Stefan Nobis proposed, the "+" sign is now not necessary:
backend-name = full export
backend-name* = only contents
And the "rest" option is introduced, with the same syntax as before.
Examples:
@foo[:export noexport]{lorem ipsum dolor}
==> does not export anything
@foo[:export contents]{lorem ipsum dolor}
==> only contents
@foo[:export latex]{lorem ipsum dolor}
==> exports only to LaTeX
@foo[:export latex odt* html*]{lorem ipsum dolor}
==> exports everything to LaTeX, but to odt and HTML only the content
@foo[:export latex* rest]{lorem ipsum dolor}
==> content to LaTeX but full export to the rest of the backends
@foo[:export latex rest*]{lorem ipsum dolor}
==> the opposite of the above.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: smallcaps: Re: Experimental public branch for inline special blocks
@ 2024-03-06 15:21 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-06 15:21 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> OK, just consider it as my dissenting opinion. I believe that it should
> be possible for the same Org document
>
> #+options: inline-special-block-aliases:(("definition" :smallcaps t))
>
> &definition{Example} or &_[:smallcaps t]{ad-hoc}
>
> to export it as
>
> <span style="font-variant:small-caps;">Example</span>
> or <span style="font-variant:small-caps;">ad-hoc</span>
>
> or as
>
> <span class="definition">Example</span>
> or <span class="small-caps">ad-hoc</span>
>
> by adjusting of global settings. The former one be suitable for a CMS
> that does not allow user CSS and the latter one is preferable for a site
> under full user control and having CSS
>
> .definition, .small-capps { font-variant: small-caps; }
With the current implementation this:
#+options: inline-special-block-aliases:(("definition" :smallcaps t))
&definition{Example}
produces:
<span style="font-variant:small-caps;" class="definition">Example</span>
:smallcaps simply adds a (say) direct formatting layer. I am not a fan
of any form of direct formatting. But, as I already said, I think that
these types of global attributes can be useful for users who do not want
to bother with predefining styles, classes or commands in
odt/html/LaTeX, or because they do not know how to do it. They simply
want a text to be exported with a certain color or with small caps, or
with more effects (in case more global attributes are implemented
(background color, text size, etc).
I think an option could be added to disable global attributes or specify
which backend they should be used on. Anyway, I would not see it
necessary, but perhaps other users think differently.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: Retaking AUTO for \usepackage{fontenc}
@ 2024-02-13 17:22 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-13 17:22 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List
Pedro Andres Aranda Gutierrez writes:
> neither do I, This is why I'm asking for people to tell me what they
> use ;-)
The babel ini files (why hadn't I thought of this before :-): look in the babel ini files:
<your-texmf-dist-root>/tex/generic/babel/locale/
There you have all the information by language. For example, in
babel-fr.ini:
8<--------------------------------------------------------------
; This file is part of babel. For further details see:
; https://www.ctan.org/pkg/babel
; Data has been collected mainly from the following sources:
; * babel language styles (license LPPL):
; https://www.ctan.org/pkg/babel-contrib
; * Common Locale Data Repository (license Unicode):
; http://cldr.unicode.org/
; http://unicode.org/copyright.html
[identification]
charset = utf8
version = 0.981
date = 2022-05-14
name.local = français
name.english = French
name.babel = french
name.polyglossia = french
tag.bcp47 = fr
language.tag.bcp47 = fr
tag.bcp47.likely = fr-Latn-FR
tag.opentype = FRA
script.name = Latin
script.tag.bcp47 = Latn
script.tag.opentype = latn
level = 1
encodings = T1 OT1 LY1 <==========================================
derivate = no
.....
-------------------------------------------------------------->8
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* [bug] Smart quotes: confusion of apostrophe with second level quotes
@ 2024-03-22 1:04 11% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-22 1:04 UTC (permalink / raw)
To: orgmode
Hi,
I don't know if this is a known issue, but I haven't been able to find
any mention of it. I think this is partly because in English it can go
perfectly unnoticed, since for English the values of secondary-closing
and apostrophe are identical:
(secondary-closing :utf-8 "’" :html "’" :latex "'" :texinfo "'")
(apostrophe :utf-8 "’" :html "’")
However, consider the following example:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
#+OPTIONS: ':t
#+language:es
"my friends' party and the students' papers"
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
the above produces in LaTeX:
\guillemotleft{}my friends'' party and the students'' papers\guillemotright{}
In Spanish, as in other similar cases, the issue is easier to reproduce
because:
(secondary-closing :utf-8 "”" :html "”" :latex "''" :texinfo "''")
(apostrophe :utf-8 "’" :html "’")
I don't know whether to consider this a bug or a limitation in the
current implementation, originating from how Org interprets an
apostrophe. Although I suspect it has a difficult solution: how to
differentiate an apostrophe from a second-level quote in certain
scenarios, when the approach seems to be essentially heuristic? Let us
also consider cases in which the apostrophe can be placed at the
beginning of a word, as in Greek:
"να 'ρθώ το βράδυ"
(Org would confuse the apostrophe in the word 'ρθώ with second-level
opening quotes)
Perhaps a possible solution would be to allow the use of a specific,
customizable character, other than an apostrophe, for second-level
quotes. Or at least add some brief warning in the manual: in certain
contexts it is safer to use a explicit Unicode character for the
apostrophe.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* [proof of concept, tip] 'Templates with arguments' using org src blocks
@ 2023-10-06 8:07 11% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-06 8:07 UTC (permalink / raw)
To: orgmode
Hi, this is a proof of concept of how a sort of 'templates with
arguments' can be used within Org, just with Org’s own resources at the
user level. It occurred to me that org src blocks might be handy for
this. For this test I just made a disguised format string using this
function:
┌────
│ (defun my-format-template (template vars)
│ (format
│"#+begin_src emacs-lisp :results raw :exports results :var template = %s
│ (format
│ (format \"%%s\" template)
│ %s)
│ #+end_src" template vars))
└────
and a macro:
┌────
│ #+MACRO: template (eval (my-format-template $1 $2))
└────
A simple example. We start from this template:
┌────
│ #+NAME: template1
│ #+begin_src org :exports none
│ ,*%s*
│ %s
│ #+end_src
│
│ #+header: :var hello = "Hello World"
│ #+header: :var str = "Lorem ipsum dolor"
│ {{{template(template1,hello str)}}}
└────
An example with a src block inside the template:
┌────
│ #+NAME: template2
│ #+begin_src org :exports none
│ ,#+begin_src emacs-lisp :exports results :results raw
│ (let ((name "%s"))
│ (format "/Hello, %%s/" name))
│ ,#+end_src
│ #+end_src
│
│ #+header: :var name = "World"
│ {{{template(template2,name)}}}
└────
And this example is somewhat more elaborate. We want a table in LaTeX
with the threeparttable package. Template:
┌────
│ #+NAME: tptable
│ #+begin_src org :exports none
│ ,#+begin_table
│ ,#+ATTR_LaTeX: :options [b]
│ ,#+begin_threeparttable
│ %s
│ ,#+begin_tablenotes
│ %s
│ ,#+end_tablenotes
│ ,#+end_threeparttable
│ ,#+end_table
│ #+end_src
└────
the table:
┌────
│ #+NAME: table1
│ #+begin_src org :exports none
│ ,#+ATTR_LaTeX: :center nil :booktabs t :float nil
│ ,#+caption: Lorem ipsum dolor
│ ,#+name: table1
│ |-------+--------------------------+-------|
│ | lorem | ipsum@@latex:\tnote{1}@@ | dolor |
│ | lorem | ipsum@@latex:\tnote{2}@@ | dolor |
│ |-------+--------------------------+-------|
│ #+end_src
└────
And, finally:
┌────
│ #+header: :var table = table1
│ #+header: :var notes = "\\item [1] First note\n\\item [2] Second note"
│ {{{template(tptable,table notes)}}}
└────
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
@ 2024-03-11 13:59 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-11 13:59 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> On 10/03/2024 09:08, Juan Manuel Macías wrote:
>> I'm thinking about adding a new global attribute, `:export', that
>> would granularly control whether or not to export the object and how to
>> export it.
>
> I have a bit different expectations in respect to export predicates.
> It should be possible to express that some content should be exported
> by all backend except the given list. The use case is fallback for
> backends not covered by export snippets:
>
> @@latex:\textbf{\LaTeX() formatting}@@@@html:<strong>HTML
> formatting</strong>@@@[...]{*for other backends}
I think that in your example (if I understand the intentions correctly)
it would not even be necessary to use export snippets:
#+options: inline-special-block-aliases:(("strong" :latex-command textbf
:html-tag strong :export "latex+ html+ odt*" ))
@strong{formatting}
or even:
@strong{@@latex:\latex{}: @@@@html:HTML: @@ formatting}
As defined, it is exported to LaTeX and HTML with all the formatting,
but only the content is exported to odt. The rest are not exported.
Maybe an "rest" option could be added, to avoid verbosity:
:export "latex+ html+ rest*"
(the complete format is exported to LaTeX and html and only the content to the rest).
However, I think that exporting this object to 'format-agnostic' backends,
such as plain text, would have to be implemented in a way that always
exports the content.
> Earlier I raised this issue during discussion of @@:...@@ syntax extension:
> Max Nikulin. Re: Org-syntax: Intra-word markup. Fri, 28 Jan 2022
> 21:52:17 +0700.
> https://list.orgmode.org/868df76e-69e0-1d14-ae8a-13b746982fcf@gmail.com
>
> Another case for backend predicates is whether it should be applicable
> to derived backends or just to explicitly specified ones.
I don't have a definite opinion. Maybe it would be nice to also take
into account derived backends...
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: [tip] Create and Insert a public Nextcloud/Owncloud link
@ 2022-10-09 12:21 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-09 12:21 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
>> Many times I need to create and share a public link to a file
>> in my local folder. In the Nextcloud forum I learned how it can be done
>> from the command line using curl,
> ..
>> │ (result-raw (shell-command-to-string
>> │ (concat "curl -u "
>> │ "\""
>> │ my-username
>> │ ":"
>> │ my-passwd
>> │ "\""
>
> Juan Manuel, your function is a nice proof of concept, but posting
> such code you are responsible for users who may try to use it verbatim
> having less experience with elisp.
>
> Use at least `shell-quote-argument' (though it docstring has a link to
> info "(elisp)Security Considerations"). Just adding quote characters
> is unsafe. You may avoid non-alphanumeric characters in passwords and
> file names for good reasons, but for other users a quote character may
> dramatically change the executed command.
>
> When TRAMP support is not necessary, arguments should be passed to
> external binary as a list without intermediate shell command. I know,
> Emacs does not have a convenience function with such calling
> convention similar to `shell-command-to-string'.
>
> I am almost sure that Emacs has a package to send HTTP POST requests
> directly from elisp. Unsure it has convenient enough API (reasonable
> default timeouts, etc.), but it should be safer for working with
> peculiar file names and passwords stuffed with characters having
> special meaning in shell. I admit that the code would be more verbose.
> It may save you time for recovering you system from damage caused by
> unexpected interpretation of a shell command.
Maxim, you are right that the use of shell-quote-argument is preferable
in cases like these to avoid unexpected problems with filenames,
passwords, and so on. I try to use it almost always. If I don't use it
more often, it's either because I'm lazy (because of my way of naming
the files, I don't expect this type of problems) or because I think it's
unnecessary, although not 100% free of danger[1], as in this case. I'm not
saying my behavior is exemplary, I'm just saying what I tend to do. I
should probably always use shell-quote-argument. In this case, the
affected part of my function would perhaps look better like this:
(shell-command-to-string
(mapconcat #'shell-quote-argument
`("curl"
"-u"
,(format
"%s:%s"
my-user
my-password)
"-H"
"OCS-APIRequest:true"
"-X"
"POST"
,(format
"%s/ocs/v1.php/apps/files_sharing/api/v1/shares"
nextcloud-url)
"-d"
,(format
"path=%s/%s"
nextcloud-public-folder-name
file)
"-d"
"shareType=3"
"-d"
"permissions=1")
" "))
[1] I think that a problem in this context would not go beyond the fact
that the function simply did not work as expected.
Perhaps it would have been better to use call-process-shell-command,
instead of shell-command-to-string, and extract the resulting string
from the output buffer.
On the other hand, I agree with you that whenever possible it is better
to use an Elisp solution than a shell command.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: Footnote tooltips (an attempt)
@ 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: `:export' attribute?: Re: Experimental public branch for inline special blocks
@ 2024-03-11 20:19 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-11 20:19 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> Your example uses a closed list of backends while "not (html or
> latex)" may be applicable to ascii, rst, some wiki dialects, etc.
Makes sense.
> Backend-specific markup may be more complex and content of fallback
> option may be different from text used in export snippets. Perhaps I
> shouldn't give so simple example.
I think I have understood the essentials, but perhaps it would be good
to see a slightly more complex scenario.
> Side note: I expect that the new object will be more convenient than
> export snippets in most cases.
I think so. In any case, although this object is proving pleasantly
versatile for us, I think we should not lose sight of the fact that its
main purpose is to be an inline text container with export properties.
Exports snippets are more for literal code inclusion. There can be
border uses between both objects, as there can also be with macros and
links. I suppose the ideal is to always choose the feature that best
suits a given context. One can put, for example @esindex[:export
latex+]{some word}, but in this case it would be more comfortable to put
@@latex:\esindex{some word}@@ or even use a macro.
>> :export "latex+ html+ rest*"
>
> "rest" might be a valid backend name.
I will try to implement the "rest" option.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: naming: Re: Experimental public branch for inline special blocks
@ 2024-03-05 15:16 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-05 15:16 UTC (permalink / raw)
To: Max Nikulin; +Cc: Ihor Radchenko, orgmode
Max Nikulin writes:
> Special blocks are really block-level elements. I see similarity,
> however with a better term we could avoid "inline" specifier. I think,
> the new beast may serve in some cases currently handled by macros.
> LaTeX snippets are named "fragments" in the manual.
>
> Custom fragment?
I think "custom" is an important part of defining the new object. Unlike
other elements/objects, such as emphasis marks, this one does not add
any (let's say) "logical or semantic" information. I mean, emphasis
marks (to continue with the example) are useful when reading an Org
document as it is. But the new object is rather a segment of text that
must be exported in a certain way to LaTeX, odt, HTML, etc. Something
like "&foo{some text}" does not provide any information to the reader,
but rather to the exporters and the output format. So, how about
something like:
- Custom Export Fragment
- Custom Export Span
- Custom Export "Whatever"
- ...
?
(I especially like "span" because of the similarity with html and family.
Pandoc uses the term bracketed spans for its custom markdown).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: [DISCUSSION] Re-design of inlinetasks
@ 2023-08-26 17:31 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-26 17:31 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
> Why not simply
>
> #+begin_anonsection
> ...
> #+end_anonsection
>
> ?
Because with an inlinetask I can have something like this:
*************** TODO anonsec :tag:
Content that has neither a title nor a section number.
*************** END
and a construction that for the purposes of parceling out the text
behaves like a section. The problem is the LaTeX side. Since there is no
support for anonymous sections in LaTeX (I seem to remember that some
special class like Koma had some command to introduce anonymous breaks,
but I only use the standard classes), I had to define an environment. It
is not inconvenient, since after all what appears in LaTeX is the
typographical result. For the Org side I can use TODO keywords, tags,
deadlines, etc.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-18 21:20 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-18 21:20 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> It seems that what I was proposing as a patch at the beginning is not,
> finally, a viable solution for all contexts...
>
> The problem is that, if the first space is removed, we get this
> abnormal result:
>
> #+begin_src emacs-lisp
> (org-sort-remove-invisible "- lo /bueno/")
> #+end_src
>
> #+RESULTS:
> : - lobueno
I wonder if this other approach can be viable or if it is something
crazy: if the spaces in org-sort-remove-invisible are a
problem only for the first emphasis of each item, how about this
fix to org-sort-list? (not modifying org-sort-remove-invisible):
@@ -2940,10 +2940,20 @@ function is being called interactively."
(org-sort-remove-invisible
(buffer-substring (match-end 0) (point-at-eol)))))
((= dcst ?a)
- (funcall case-func
- (org-sort-remove-invisible
- (buffer-substring
- (match-end 0) (point-at-eol)))))
+ (if (save-excursion
+ (beginning-of-line)
+ (forward-char)
+ (looking-at-p org-emph-re))
+ (replace-regexp-in-string
+ "\\(^\\)\s+" "\\1"
+ (funcall case-func
+ (org-sort-remove-invisible
+ (buffer-substring
+ (match-end 0) (point-at-eol)))))
+ (funcall case-func
+ (org-sort-remove-invisible
+ (buffer-substring
+ (match-end 0) (point-at-eol))))))
((= dcst ?t)
(cond
;; If it is a timer list, convert timer to seconds
^ permalink raw reply [relevance 11%]
* Re: [BUG] Footnotes in section titles
@ 2024-01-26 13:17 11% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-26 13:17 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Colin Baxter, Max Nikulin, Eric Anderson, ihor Timothy, orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> ...
>> \title{Lorem ipsum dolor\thanks{blah blah}}
>> ...
>>
>> Org does not have support for this type of notes in the #+title or
>> #+author keywords. For LaTeX you can use a macro.
>
> Hmm.
> The reason footnotes are not allowed in #+title and other keywords is
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7ebe87e2d5fb6c
>
> Inserting footnote references in parsed keywords (e.g., TITLE or
> CAPTION) can lead to subtle bugs. Indeed, it is impossible to know in
> time if that particular footnote is going to be used in the output,
> and, therefore, if it should count, e.g., in
> `org-export-get-footnote-number'.
>
> However, I am not sure about that line of reasoning - we generally don't
> know if *any* given footnote reference is going to be used in the output
> or not because export backend may skip references or whole parts of the
> original Org file. Same for user filters.
>
> So, I am leaning towards reverting that commit - that will allow things
> like
>
> #+TITLE: This is a test title[fn::This is test]
>
> If we need special handling for footnotes in title (like using \thanks
> instead of \footnote), it is easy.
I completely agree. I think it would be a great improvement, since, as
Colin Baxter says, in academic articles it is a very common practice to
add foot notes to the title of the article or the name of the author.
As for the \thanks{} command, org exports the keyword #+email within a
\thanks{} command as '\author{Name\thanks{email}}0. I don't think two
\thanks macros collide within author (assuming the user adds the email
and puts a footnote in #+author. Anyway, I think the most common thing
is to put the email below the author's name, not as a footnote, but that
is another topic and also depends on the style of each publication,
journal, etc.
>> ... For backends like odt
>> it is trickier. Look at this thread:
>>
>> https://lists.gnu.org/archive/html/emacs-humanities/2024-01/msg00000.html
>>
>> I think it would be nice if Org had some kind of support for notes in
>> #+title and #+author...
>
> No idea about how to do it in ODT. If someone familiar with OpenDocument
> spec can help, it would be welcome.
I don't have much idea about odt, but I think the problem comes from a
type of nesting that is not allowed in the odt xml. I think org exports
#+author inside the initial-creator tag:
(format "<meta:initial-creator>%s</meta:initial-creator>\n" author)
And within that tag the code for a footnote produces an error when
opening the document. If the footnote is placed right after
</meta:initial-creator>, there would be no problem.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
@ 2023-10-01 17:48 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-01 17:48 UTC (permalink / raw)
To: AW; +Cc: emacs-orgmode
Max Nikulin writes:
> On 28/09/2023 22:36, AW wrote:
>>
>> The idea to have a LATEX_PRE_HEADER to insert `\DocumentMetadata{}` is exactly
>> what you need right now, if you export from orgmode to current LaTeX. With
>> `\DocumentMetadata{}` you can add most of the necessary xmp data -- and I
>> write most, because I'm using it on a daily basis, but haven't checked if
>> really everything is included yet.
>
> The question is if Juan Manuel can use \DocumentMetadata instead of the
> pdfx package in his workflow.
I'm afraid that with the pdfx example that I put in the first post I
have caused a little confusion. pdfx is not part of my workflow. I only
used it once a long time ago. I've cited the code from that package here
as another example of arbitrary code that can be placed before
\documentclass. As I said, there are many more examples and possible
cases: \DocumentMetadata and \PassOptionsToPackage are two typical
cases. But, as I have already mentioned, /almost/ any LaTeX code can be
accommodated before class declaration. Even simple comments. Why not
think about a hypothetical case in which a user needs to create from Org
a *.tex file that contains comments before \documentclass? With a
LaTeX_pre_header keyword that would be possible.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
@ 2023-08-15 14:25 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-15 14:25 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Sure, but look at the pdf. The generated pdfs are not different for some
> reason.
Ah, sorry. It was a foolish oversight of mine. The point is that a
\vspace after a line break in normal text has no effect. This does work:
lorem ipsum\\
\vspace*{10ex}\\
dolor
but it's a dirty workaround. In addition, there are more problems that I
had not noticed. If it is normal text, LaTeX indents the first line. A
\parindent=0 should be added, but that means complicating things
unnecessarily...
I think the best thing is to rethink the :literal attribute, as I
commented at the end of my other email:
- without :literal --> verse environment with a more "canonical" syntax.
- with :literal --> verse environment seen in the "old (org) style",
preserving the blank lines. In that context \vspace does work.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: Exporting multiple #+AUTHOR keywords
@ 2024-02-02 22:26 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-02 22:26 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Sorry if this is off topic, but something like this:
>>
>> #+AUTHOR: Fred Astaire
>> #+AUTHOR: Ginger Rogers
>>
>> is exported to LaTeX as:
>>
>> \author{Fred Astaire Ginger Rogers}
>>
>> Shouldn't there be some separation? In LaTeX the usual thing is:
>>
>> \author{Fred Astaire \and Ginger Rogers}
>
> You can do
>
> #+AUTHOR: Fred
> #+AUTHOR: Astaire
>
> #+AUTHOR: and Ginger
> #+AUTHOR: Rogers
>
> The values are simply concatenated before passing to the exporter.
>
> Can we concatenate with "\and"? Sure. But not by default or it would be
> a breaking change.
Thanks for the explanation. I've never made documents with more than one
author, so I've never thought about this scenario. For a moment I
thought org supported more than one author (explicitly, I mean).
Anyway, \and is just a formatting command: add a space between two
authors. Some people may prefer to put a line break \\ or anything else.
Of course, \and (and any other format command) will have a negative
effect on the pdfauthor metadata, which only collects text strings. It
is a similar problem to the one with footnotes, which Maxim commented
on. I think the basic problem is that org uses #+author, #+title, etc.
as a single source for both the metadata strings and the exported
format, i.e. the title, the author, the date that is printed somewhere.
Perhaps the ideal would be to distinguish in some way between
author-metadata and author-exported-format. For example something like:
#+AUTHOR[John Doe and Luke Skywalker]: John Doe @@latex:\and@@ Luke
Skywalker
The optional string in square brackets would be the metadata; the rest
would be the direct exported format. If there is no optional string, the
value is used for both metadata and format. Could this be also a
possible solution to the footnote problem?
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
@ 2024-01-02 23:46 11% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-02 23:46 UTC (permalink / raw)
To: orgmode
Hi,
I recently discovered that if the last line of a LaTeX 'verse'
environment ends in '\\[0pt]', the space after the environment is
drastically altered. The space after a 'verse' environment (which is a
modified list environment) must be equivalent to
\partopsep+\topsep+\baselineskip. I have done the test with a document,
defining a rectangle of that height with tikz, where you can see the
difference in vertical space with and without '\\[0pt]':
https://i.imgur.com/khbboDZ.png
Naturally, this implies an issue when exporting the verse block to
LaTeX, since the presence of the '\\[0pt]' string alters the expected
result in the compiled PDF. My suggestion is that the last line of the
verse block is not exported with either the string '[0pt]' or the line
break mark '\\', since it makes no sense for that mark to be there: it
is the end of a paragraph and the very end of the environment.
Can anyone think of a possible scenario where removing the '\\[0pt]' in
the last line would cause a problem? If not, I might send a patch in the
next few days. (I'm afraid that going back to abusing
replace-regexp-in-string. I can't think of any other more elegant
solution...).
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: [patch] Add two new header args to LaTeX block
@ 2024-02-13 20:25 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-13 20:25 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> Moreover, it would be nice to unify handling .png and imagemagick
>>> branches of the code.
>>
>> I agree. In any case, I still think that the coexistence of two methods
>> to convert to images, when one of the methods has a scheme so different
>> from the rest, becomes difficult: for the user as well as for
>> maintaining the code.
>>
>> The first solution that occurs to me (I'm afraid it's too radical) is to
>> leave only the :imagemagick method, and maintain the possibility of
>> using the other one through a variable. Something like
>> org-babel-latex-default-image-conversion-method or something similar.
>> But I suppose this could cause unwanted inconveniences. We should see
>> what more users think.
>
> I am not sure.
> Conceptually, .png method is more flexible than imagemagick - it uses
> `org-create-formula-image' that is handling (1) preamble; (2) conversion
> not only to png but to svg and other arbitrary formats.
> ob-latex is duplicating org-create-formula-image code, layering custom
> latex preamble and more commands on top.
> So, ideally, I'd prefer to obsolete the custom code in ob-latex and make
> use of `org-create-formula-image', possibly extending it to fit ob-latex
> needs.
It is true that the "org-create-formula-image" method is much more
complete. But, IMHO, I think it's a method focused on the buffer (rather
than the block) or previewing LaTeX code in the buffer. In the case of
the LaTeX block, I think the :imagemagick method is simpler. It depends
on two simple processes: imagemagick and org-latex-pdf-process and
parameters such as the width or height of the generated image, the
density in dpi, etc. can be easily applied, via arguments. In the case
of the other method, in addition to the value of
org-preview-latex-default-process, there is that of
org-format-latex-options. There are, in short, many parameters that are
perfect for a file or an Emacs session but for a simple block I find
overhelming.
In any case, if the org-create-formula-image method is going to stay, I
think it is fine as it is (except for extending the allowed file formats
to more extensions, and not only .png). I also believe that the :process
argument is sufficient for the user to control the value of
org-latex-pdf-process or org-preview-latex-default-process, as
appropriate.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: Link type for pdf-tools annotations
@ 2024-02-09 0:40 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-09 0:40 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Many times I need to "save" an annotation point in the pdf-tools
>> annotations buffer. So I defined a new link type and the function to
>> store it. The link is stored with the structure:
>>
>> [[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p. page-number)]]
>>
>> The link opens the PDF and jumps to the specific annotation.
>
> You may also utilize `org-create-file-search-functions' and
> `org-execute-file-search-functions' to make an ordinary file: links
> works for the same purpose.
Thanks for the pointers. Note that in this use case I don't need to
search in the PDF file itself but in the pdf-annot-list-mode buffer that
is created via pdf-annot-list-annotations. This buffer is synchronized
with the PDF to which it is linked. What this link type does is visit
the pdf file (with pdf-tools), create the list of annotations and jump
to the specific annotation, by date.
pdf-annot-list-display-annotation-from-id highlights the specific list
annotation in the linked PDF (if necessary, moves to the corresponding
page), and opens the content of the annotation in another window
(interactively the function is executed by pressing SPC on the
annotation list at point). Storing the annotation date seemed like the
safest option to me, since the annotation id can change when adding new
annotations, each time the list is created. The typical scenario: when I
am consulting a PDF annotated by someone and I want to store the
location of some specific annotations. As there can be many annotations
per page, adding a simple bookmark to the page would not be enough
either.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
@ 2022-09-24 14:50 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-24 14:50 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi, Ihor, sorry for the late reply,
Ihor Radchenko writes:
> Having read the available replies in this thread, I am thinking of the
> following:
>
> 1. Instead of explicit prefix and suffix, we can unify extra text around
> the exported Org element to a template:
>
> * headline
> :PROPERTIES:
> :ATTR_BACKEND: :export_template "\begin{myenv}\n%s\n\end{myenv}"
> :ATTR_BACKEND+: "The %%s instances are replaced by the exported element"
> :ATTR_BACKEND+: (concat "arbitrary sexp, the exported element is bound to: " *this*)
> :ATTR_BACKEND+: babel_block_name(exported=*this*)
> :ATTR_BACKEND+: "the property lines are concatenated with \" \" (space),"
> :ATTR_BACKEND+: "just like the usual approach in `org-export-read-attribute'"
> :END:
I really like this approach and I would buy it. On the one hand, if I
understand correctly, it's a universal solution that doesn't depend on a
particular backend (although, to be honest, I don't see much use for
this beyond LaTeX: maybe in HTML). And, on the other hand,
`:export_template' is an attribute that can be, as you say, very
versatile. With this, in my opinion, it would no longer be necessary to
define two 'pre' and 'post' attributes.
I imagine the value of ATTR_BACKEND (would quotes be necessary?) could
be easily converted to a plist, with code borrowed from
`org-export-read-attribute':
(:export_template "\\begin{myenv}\\n%s\\n\\end{myenv} ... etc. ...")
> #+ATTR_BACKEND: :export_template "can also work on non-headings"
> Paragraph.
In this case I would not see it necessary, IMHO. For simple things (of
the begin/end style) there are the special blocks. And for more complex
pre- and/or post- code we have export blocks and export snippets. Since
there is no heading involved here, there would be no danger of the
pre-code leaving with the content of the previous header.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* [patch] ox.latex.el: Add missing character warnings
@ 2024-02-12 15:24 11% Juan Manuel Macías
2024-02-12 18:15 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-12 15:24 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
Rationale for the attached patch: It seems that a common problem that
users have with exporting to LaTeX is unicode characters that cannot be
represented in pdfLaTeX or LuaLaTeX/XelaTeX. In the Unicode TeX engines
the warning is insidious, since the missing character warning is not
preceded by a 'warning' string.
Naturally, the added Org warnings do not solve the problem, but at least
they give some clues on how to properly adjust the document.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Add-missing-character-warnings.patch --]
[-- Type: text/x-patch, Size: 1247 bytes --]
From 03c4c94c22f720e38f1ffb180aaa8a23abd90406 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 12 Feb 2024 16:10:28 +0100
Subject: [PATCH] lisp/ox-latex.el: Add missing character warnings
* (org-latex-known-warnings): Two missing character warnings are
added: one for LuaLaTeX/XelaTeX and another for pdfLaTeX.
---
lisp/ox-latex.el | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..80d992160 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1511,6 +1511,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'."
("Underfull \\hbox" . "[underfull hbox]")
("Overfull \\hbox" . "[overfull hbox]")
("Citation.*?undefined" . "[undefined citation]")
+ ("LaTeX Error: Unicode character" . "[character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]")
+ ("Missing character: There is no" . "[Missing character(s): please load an appropriate font with the fontspec package]")
("Undefined control sequence" . "[undefined control sequence]"))
"Alist of regular expressions and associated messages for the user.
The regular expressions are used to find possible warnings in the
--
2.43.1
^ permalink raw reply related [relevance 11%]
* Re: [patch] ox.latex.el: Add missing character warnings
2024-02-12 15:24 11% [patch] ox.latex.el: Add missing character warnings Juan Manuel Macías
@ 2024-02-12 18:15 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-12 18:15 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
Sorry, the previous patch was incomplete. The attached patch is correct.
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Rationale for the attached patch: It seems that a common problem that
> users have with exporting to LaTeX is unicode characters that cannot be
> represented in pdfLaTeX or LuaLaTeX/XelaTeX. In the Unicode TeX engines
> the warning is insidious, since the missing character warning is not
> preceded by a 'warning' string.
>
> Naturally, the added Org warnings do not solve the problem, but at least
> they give some clues on how to properly adjust the document.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Add-missing-character-warnings.patch --]
[-- Type: text/x-patch, Size: 1825 bytes --]
From 19fb7b81d6ce3a657c86497707f590063b27683c Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 12 Feb 2024 16:10:28 +0100
Subject: [PATCH] lisp/ox-latex.el: Add missing character warnings
* (org-latex-known-warnings): Two missing character warnings are
added: one for LuaLaTeX/XelaTeX and another for pdfLaTeX.
---
lisp/ox-latex.el | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..da4792c04 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1511,6 +1511,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'."
("Underfull \\hbox" . "[underfull hbox]")
("Overfull \\hbox" . "[overfull hbox]")
("Citation.*?undefined" . "[undefined citation]")
+ ("LaTeX Error: Unicode character" . "[unicode character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]")
+ ("Missing character: There is no" . "[Missing character(s): please load an appropriate font with the fontspec package]")
("Undefined control sequence" . "[undefined control sequence]"))
"Alist of regular expressions and associated messages for the user.
The regular expressions are used to find possible warnings in the
@@ -4435,7 +4437,11 @@ encountered or nil if there was none."
(save-excursion
(goto-char (point-max))
(when (re-search-backward "^[ \t]*This is .*?TeX.*?Version" nil t)
- (if (re-search-forward "^!" nil t) 'error
+ (if (and
+ (re-search-forward "^!\\(.+\\)" nil t)
+ ;; This error is passed as missing character warning
+ (not (string-match-p "Unicode character" (match-string 1))))
+ 'error
(let ((case-fold-search t)
(warnings ""))
(dolist (warning org-latex-known-warnings)
--
2.43.1
^ permalink raw reply related [relevance 12%]
* Re: [BUG] Underlined text in parentheses is not exported correctly
@ 2021-12-31 11:08 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-31 11:08 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> If I do M-! (occur org-match-substring-regexp)
>
> I get:
>
> 10:(_underline_)
> 22:(_underline_ text)
Well, in my case the temporary workaround was to force super/subscripts
with braces:
#+begin_src emacs-lisp
(defun my-org-element-subscript-with-braces-parser ()
(save-excursion
(unless (bolp) (backward-char))
(when (looking-at org-match-substring-with-braces-regexp)
(let ((bracketsp (match-beginning 4))
(begin (match-beginning 2))
(contents-begin (or (match-beginning 4)
(match-beginning 3)))
(contents-end (or (match-end 4) (match-end 3)))
(post-blank (progn (goto-char (match-end 0))
(skip-chars-forward " \t")))
(end (point)))
(list 'subscript
(list :begin begin
:end end
:use-brackets-p bracketsp
:contents-begin contents-begin
:contents-end contents-end
:post-blank post-blank))))))
(advice-add 'org-element-subscript-parser :override #'my-org-element-subscript-with-braces-parser)
#+end_src
^ permalink raw reply [relevance 12%]
* Re: A question about local/experimental branches
@ 2024-02-25 15:10 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-25 15:10 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Bastien, orgmode
Ihor Radchenko writes:
> P.S. Juan, I will need some time to review previous discussions on
> inline special blocks before I can comment on your work in depth.
No problem, Ihor. These days I had enough free time to develop my idea,
translate it into code and get something usable from which it could be
discussed. As I mentioned, the export to HTML and LaTeX is complete and
works fine, but I'll probably stop there for a long time. I mean, I
won't go any further and I will dedicate myself to continuing testing
the code already written and fixing possible bugs. Partly because I
don't have enough knowledge of odt to work on this backend, which would
be the next step.
Thanks for the info!
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-14 21:36 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-14 21:36 UTC (permalink / raw)
To: orgmode
Hello again,
Since I have an old Emacs version (24.5.1) on my Raspberry, I've done
a few more tests. The situation is the following:
1. On Arch Linux and Emacs 27.2:
- The system locales are set to "es_ES.UTF-8". When, inside Emacs, I do M-x
getenv RET LANG RET, I get "es_ES.UTF-8".
org-sort-list a -> wrong result;
- Launching Emacs from terminal with
LANG=es_ES.UTF-8 \
etc...
org-sort-list a -> wrong result again.
2. On Fedora 32 (virtual machine) and Emacs 27.1
- Everything as in the previous case.
3. On Raspian stretch and Emacs 24.5.1:
- The system locales are set to "es_ES.UTF-8" as well. When, inside a
normal Emacs session, I do M-x getenv RET lang RET, I get "es_ES.UTF-8".
org-sort-list a -> wrong result;
- Launching Emacs from terminal with
LANG=es_ES.UTF-8 \
etc...
In this case the list is ordered correctly, but I observe that similar
forms with or without emphasis are not always ordered in the same way.
Sometimes the non-emphasized forms are ordered before and sometimes
they are ordered after (?).
I don't know if I'm missing something...
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Hi Maxim,
>
> Thanks again. In my case, I keep getting the wrong result. In addition
> to the test I did in a virtual machine with Fedora, I use Arch Linux in
> my every day computers, with locales correctly (I hope) configured as
> es_ES.UTF-8 (there was a typo in my previous mail, sorry:
> 'en_ES.UTF-8'). In my /etc/locale.conf file I have:
>
> LANG=es_ES.UTF-8
> LC_ADDRESS=es_ES.UTF-8
> LC_IDENTIFICATION=es_ES.UTF-8
> LC_MEASUREMENT=es_ES.UTF-8
> LC_MONETARY=es_ES.UTF-8
> LC_NAME=es_ES.UTF-8
> LC_NUMERIC=es_ES.UTF-8
> LC_PAPER=es_ES.UTF-8
> LC_TELEPHONE=es_ES.UTF-8
> LC_TIME=es_ES.UTF-8
>
> And with locale -a, I get a list of enabled locales:
>
> C
> en_US.utf8
> es_ES.utf8
> POSIX
>
> However, I keep getting the wrong result :-( (Arch, Emacs 27.2).
>
> Even with
>
> LANG=en_EN.UTF-8 \
> emacs -nw -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
> list.org
>
> Maybe the problem is on Arch's side (?), although it was also reproducible
> in the test I did with Fedora in virtual machine and Emacs 27.
>
> Best regards,
>
> Juan Manuel
>
> Maxim Nikulin writes:
>
>> On 14/04/2021 02:08, Juan Manuel Macías wrote:
>>> The situation is that with locales configured for Spanish from Spain
>>> (en_ES.UTF-8) the list is not ordered correctly, unless those three
>>> spaces from org-sort-remove-invisible are removed. But I couldn't say
>>> why or if that would be appropriate as a patch...
>>
>> Did not you get a warning like the following one?
>>
>> (process:220): Gtk-WARNING **: 15:17:45.066: Locale not supported by C
>> library.
>> Using the fallback 'C' locale.
>>
>>> Regarding the collation rule of forms with emphasis, at least in Spanish
>>> these should come after the non-emphasized forms. I don't know if this
>>> is a general rule also for other languages (at least it seems more
>>> natural that the forms without emphasis are placed before).
>>
>> LANG=es_ES.UTF-8 \
>> emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
>> list.org
>>
>> - a
>> - /a/
>> - v
>> - /v/
>>
>> So it works accordingly to your expectation. Emacs 25.2.2,
>> Ubuntu-18.04 container.
>>
>> I have generated es_ES.UTF-8 locale using
>>
>> dpkg-reconfigure locales
>>
>> Depending on linux distribution you run, the locale may be ready to
>> use or not. I tend to think that in minimal environment of virtual
>> machine it was missed.
>>
>> I had an idea to add a test for sorting of items including emphasized
>> ones but test-org-list/sort forces C locale. Maybe it was done to
>> avoid failures due to missed locale.
>>
>>
>
^ permalink raw reply [relevance 12%]
* [Question] A single *-language-alist in ox-latex.el?
@ 2021-10-02 10:48 12% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-02 10:48 UTC (permalink / raw)
To: orgmode
Hi,
I have seen that `org-latex-polyglossia-language-alist' contains far
more languages than `org-latex-babel-language-alist'.
Well, if I'm not mistaken, the situation in the LaTeX ecosystem is this:
Polyglossia appeared as a babel replacement for XelaTeX and LuaLaTeX,
since babel, at that time, had no support for these two new Unicode
based TeX engines. I think those two separate lists in ox-latex.el
translate that situation. But the reality is different now: babel has
full support now for LuaTeX and XeTeX and supports more languages than
polyglossia (and also supports language variants. See
http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf p.
20). In addition, babel is part of the LaTeX core and is, therefore,
better mantained.
Of course, anyone who wants to use polyglossia in their documents can
keep doing it without problems. But I think it does not make much sense
to mantain in ox-latex.el two separate lists today. Maybe, for
simplicity, it would be better to unify the two lists in a single db,
something like `org-latex-language-alist'. What do you think?
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 12%]
* Re: Raw Org AST snippets for "impossible" markup
@ 2021-12-09 22:27 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-09 22:27 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Juan Manuel Macías writes:
> Jumping into the "real world", how about these two examples of nested emphasis?
By the way, what do you think about allowing the use of some kind of
aliases, so that the aspect is less verbose? Maybe something like "(i::"
instead of "(italic () ..."? I came up with this hasty sketch over your
latest code, *just* to see how it looks (I don't know if I prefer it to
stay verbose):
#+begin_src emacs-lisp :results silent
(setq orgia-alias-alist '(("i" "italic")
("b" "bold")
("u" "underline")
("s" "strike-through")))
(defun orgia-replace (before after)
(interactive)
(save-excursion
(goto-char (point-min))
(while (re-search-forward before nil t)
(replace-match after t nil))))
(defun orgia--transform-path (path)
(with-temp-buffer
(insert path)
(mapc (lambda (el)
(orgia-replace (concat "(" (car el) "::") (concat "(" (cadr el) " () ")))
orgia-alias-alist)
(buffer-string)))
(defun orgia--transform-link (data)
(if (not (string-equal "orgia" (org-element-property :type data)))
data
(let* ((path (org-element-property :path data)))
(if (not (eq ?\( (aref path 0)))
(or path (org-element-contents data))
(read (orgia--transform-path path)))))) ;; <====
;;;;;;;;;;;;;;;;;;
#+end_src
#+begin_src elisp
(org-export-string-as "An <orgia:(\"in\" (s:: \"ter\"))>word"
'odt t)
#+end_src
#+RESULTS:
:
: <text:p text:style-name="Text_20_body">An in<text:span text:style-name="Strikethrough">ter</text:span>word</text:p>
#+begin_src org :results latex :results replace
[[orgia:(i:: "The English versions of the " (b:: (i:: "Iliad")) " and the " (b:: (i::
"Odyssey")))]]
#+end_src
#+RESULTS:
#+begin_export latex
\emph{The English versions of the \textbf{\emph{Iliad}} and the \textbf{\emph{Odyssey}}}
#+end_export
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 12%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
@ 2023-09-24 18:42 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-24 18:42 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> On 17/09/2023 01:00, Juan Manuel Macías wrote:
>>
>> [1] A longer example to export to a pdf that has pdf-x compliance, with
>> the pdfx package:
>>
>> \providecommand{\pdfxopts}{x-1a}
>> \begin{filecontents*}{\jobname.xmpdata}
>> \Title{Some Title}
>> \Author{Author}
>> \Language{es-ES}
>> \Keywords{keywords}
>> \Publisher{publisher}
>> \end{filecontents*}
>> \documentclass{...
>
> Perhaps you have in mind other cases, but I am unsure concerning this
> one. However I have tried only setting metadata for hyperref only, so I
> may miss some important aspects.
>
> First of all, I was unaware of .xmpdata and, trying to get more info, I
> have found hyperxmp that declares to reuse data from \hypersetup without
> extra files and without the requirement to add settings before
> \documentclass.
According to the pdfx package documentation
(https://www.ctan.org/pkg/pdfx), p. 6 (at the bottom of the page)/7:
---
Warning: The \jobname.xmpdata file may be included in the main document
source, within a {filecontents*} environment, provided this comes before
the \documentclass command, as follows[...]
---
> Do you need to add commands before \documentclass because you are using
> custom classes that loads a lot of packages, so there is no chance to
> specify various options after \documentclass, but before specific
> packages are loaded?
Apart from the previous case, there are other varied cases (as I
mentioned) in which it is necessary to put code before documentclass.
For example, the newpax package, to preserve the internal links of a pdf
included in the document, requires putting commands like
\DocumentMetadata{ } before documentclass.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: [patch] Fix inner smart quotes in French
@ 2023-08-05 10:51 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-05 10:51 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi, Ihor,
Ihor Radchenko writes:
> Welcome back :)
thanks! :-)
>> In the meantime, I'm submitting this patch with a fix for second-level
>> French `smart quotes': the correct quotes should be “” (without spaces,
>> as in Spanish or Greek) (please, some francophone correct me, if I'm
>> wrong...).
>
> The patch does not update the tests. So, we now have
> FAILED 644/1151 test-org-export/activate-smart-quotes
>
> And it looks like at least on of the test conditions is not trivial to
> fix without knowing French. May you or somebody familiar with French
> punctuation take a look?
I'm afraid I'm not very familiar with the syntax and usage of tests, so
I have to study that part. I've been looking at
`test-org-export/activate-smart-quotes', and I have a question: does it
only include tests for English and French cases?
First level quotes for French are «» with spaces, and second level ones
(if I'm not mistaken) should be “”, without spaces (my patch fix).
Therefore, I understand that a line like:
(equal '( "« outer « inner » outer »")
should it be changed like this
(equal '( "« outer “inner” outer »")
?
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
@ 2024-03-13 16:48 12% ` Juan Manuel Macías
2024-03-13 17:16 14% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-13 16:48 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
>> how about the following:
>> - "--" :: do not export
>> - "**" :: export only the content
>> - "==" :: rest (full)
>> - "=*" :: rest (only the content)
>> - "!backend-name+ :: export this backend (full)
>> - "!backend-name*" :: export this backend (only the content)
>> - "!backend-name- :: do not export this backend
>
> I do not see why operator should be duplicated for backends that are not
> specified explicitly. Single "+" (default) or "-" should be enough. I
> have not got your idea with leading "!". From my point of view it is
> redundant.
It was necessary with the previous implementation, which excessively
abused regexp. Not now (I want to do a few more tests and I'll make a
new commit with the changes). With the new implementation, now:
- do not export
* export only the content
= rest (full)
=* rest (contents only)
backend- do not export this backend (and the backends derived from it)
backend+ (or, perhaps, just "backend") export this backend (idem)
backend* export this backend (contents only) (idem)
I think your example with the video link would also be possible with the
new implementation.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: Help with a (query) replacement
@ 2022-11-12 16:29 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-12 16:29 UTC (permalink / raw)
To: Ypo; +Cc: Org-mode
Juan Manuel Macías writes:
> In the case of PDFs, I would use pdftotext. It converts the PDF to plain
> text and (in theory) removes hyphens from the PDF after conversion. The
> resulting plain text is somewhat ugly (page numbers and other elements
> are preserved), but if you just want to copy/paste text, I think it's
> enough.
And if you don't want to mess with the command line, you can also use
calibre here to convert from PDF to plain text or even Epub (the latter
is better because Epub is a tagged format and then you can have more
control over how to process that, for example by converting it to Org or
Markdown with pandoc). Calibre will do its best to preserve the
structure of the PDF, removing hyphens and other unnecessary elements.
But keep in mind that this process is largely heuristic, and the
conversion is not 100% perfect. However, it works acceptably well.
https://calibre-ebook.com/about
^ permalink raw reply [relevance 12%]
* Re: Fallback fonts in LaTeX export for non latin scripts
@ 2023-09-24 18:24 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-24 18:24 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Timothy, Max Nikulin
Sorry for the late reply.
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> [...] I am very interested in all possible improvements in babel so that
>> it integrates as best as possible with automatically generated files.
>> Among them are the possibility of using BCP47 codes or using a language
>> (at least basically) without the need for a prior declaration. These are
>> things already done, but there are others that can still be improved.
>
> Do I understand correctly that babel, in future, may be able to
> auto-detect more languages without explicitly declaring them?
Correct. Indeed, it is possible to use the command \foreignlanguage or
its environment version (otherlanguage*) without having to
declare the language previously. I would say that \foreignlanguage is a
command that covers a high percentage of use cases in multilingual
documents, since it is intended for short fragments of text and only
loads the hyphen rules of the host language.
>> [...] any suggestion for improvement is very welcome [...]
>
> This is a bit too out of context. Improvement of what?
I think it is related to the previous paragraph: "I am very interested
in all possible improvements in babel so that it integrates as best as
possible with automatically generated files[...]"
>> Among the things I agree on is name issue. I am unifying the dice in the
>> CLDR as much as possible, and already, in fact, it is very advanced:
>>
>> https://latex3.github.io/babel/guides/locale-naming.html
>
> AFAIU, the relevant quote is
>
> They are taken from the CLDR. Wherever the CLDR doesn’t provide a name
> (eg, “Medieval Latin”), the pattern followed in practice for other names
> is applied, namely, use the ‘natural’ form in English: medievallatin.
> They should be preferably based on the description field in the IANA
> registry (eg, polytonicgreek), although some simplifications can be
> necessary, because some names are “too” descriptive. See also the
> templates for about 500 locales already available. As a secondary
> source, Glottolog is used, too. (Wikipedia articles can be taken as a
> complementary but unreliable source, and its information must be
> verified; on the other hand, internal data, like this one, is useful for
> both names and tags.)
>
> I am not very sure about "some simplifications" referring to IANA. I
> guess it is referring to language names in
> https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
> like "Puter idiom of Romansh".
>
> From Org perspective, verbosity is not a primary concern as long as we
> provide #+language: completion support. Probably, we should favor names
> that are more likely known (or can be easily found) by the language
> users. IANA and https://glottolog.org/ look like good sources we can
> link to.
>
> We can also provide multiple language name variants though I don't see a
> need to bother unless we get user requests to do such thing.
I agree. I even think it would be a good point to also include the
vernacular name of each language.
By the way, Javier has also told me that he is going to consider the
'onchar=ids fonts' issue related to the case of several languages that
use the same script (already discussed here in past messages).
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: Question Regarding Creating HTML Style Buttons With Org Mode
@ 2022-02-19 9:51 12% ` Juan Manuel Macías
0 siblings, 0 replies; 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: New try at multi-lingual export to latex/pdf using pdflatex and babel
@ 2024-02-11 11:04 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-11 11:04 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List
Pedro Andres Aranda Gutierrez writes:
> I agree it does not take advantage of the AUTO facility here, but I
> nevertheless think it would
> be interesting to show people how to do this. Until we expand the AUTO
> facility to cope with
> all quirks of multi-language in pdflatex (lualatex and xetex are a
> different pair of shoes), a quick
> and dirty alternative may be helpful for people. The introductory text
> could be
Pedro, the only problem I see with that is that it is an example of
LaTeX rather than Org. The only Org part here is #+LaTeX_header, and in
the entire section it's already made clear enough what it's used for.
Perhaps a brief reminder (the AUTO facility of the previous examples
is very limited) could be added first, and that if the users want to
obtain more complex, or more specific results (like the case you
exemplify for pdfLaTeX) they must put explicit LaTeX code, using
LaTeX_header. And then your example would come, but emphasizing that the
LaTeX documentation must be consulted. wdyt?
My point is that if we abuse examples of this type (at the expense of
"#+latex_header:something"), or "how is this done in LaTeX?", in the end
a LaTeX manual is made instead of Org.
I'm glad you enjoyed the jump to LuaTeX. :-)
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: [Question] A single *-language-alist in ox-latex.el?
@ 2021-10-02 19:20 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-02 19:20 UTC (permalink / raw)
To: Stefan Nobis; +Cc: orgmode
Hi Stefan,
Stefan Nobis writes:
> And, as far as I remember, babel development had nearly ceased during
> that period.
>
> Since quite some years, the development has gained much more traction
> for babel and, as far as I read, babel is today as good or superior to
> polyglossia in many regards (but polyglossia is also in quite a good
> shape today). See for example:
>
> https://tex.stackexchange.com/questions/482396/decide-between-polyglossia-and-babel-for-lualatex-in-2019
>
> In short: Babel is a very good choice in almost all cases, maybe
> except for right-to-left texts set with XeLaTeX.
Indeed, Javier Bezos (who is also the author of very popular packages
like enumitem or titlesec/titletoc) is doing a great job with Babel (you can
see the latest news here: https://latex3.github.io/babel/). And he has
added a lot of powerful features, such as babel replacements (with Lua code)
or the possibility to load languages via ini files and define new
languages with \babelprovide
I've been doing some testing, and I think this hypothetical new
unified list could support two types of members:
1. A member with 2 elements:
("lang-id" "lang-name"),
i.e.: ("it" "italian")
2. A member with 4 elements (for variants):
("lang-id" "babel-lang-name" "polyglossia-lang-name" "polyglossia-variant")
i.e.: ("la-classic" "classiclatin" "latin" "classic")
And then it would be necessary to make some minor modifications in
org-latex-guess-polyglossia-language and org-latex-guess-babel-language.
I will try to write a patch (or at least a proof of concept) in the next days ...
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 12%]
* Doubts about a function for my org-capture template
@ 2022-10-15 15:14 12% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-15 15:14 UTC (permalink / raw)
To: orgmode
Hi all,
I have written this function to be able to choose the type of block in
which to enclose the marked content (by default, quote). So in
my org-capture template I put %(my-capture-block) instead of %i:
┌────
│ (defun my-capture-block ()
│ (let ((initial (org-capture-get :initial)))
│ (when initial
│ (let ((block-name
│ (read-string
│ "Block type for marked content (default quote): "
│ nil nil "quote")))
│ (format
│ "#+begin_%s\n%s\n#+end_%s"
│ block-name
│ initial
│ (if (string-match "\\(src\\)\\(.+\\)" block-name)
│ (match-string 1 block-name)
│ block-name))))))
└────
The function works fine from eww, but it doesn't work with org-protocol
+ qutebrowser, as the value of :initial in org-capture-plist seems to be
nil. I've solved it by enclosing %i between two sexp %(...), one to
format the #+begin_xxx and the other to guess the #+end_xxx, but it's
more verbose. Does anyone have a clue how to get the value of %i for
org-protocol with a function inside the template?
Best regards and happy weekend,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: Fallback fonts in LaTeX export for non latin scripts
@ 2023-09-05 18:33 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-05 18:33 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Max Nikulin writes:
> Cyrillic letters may appear not only in Russian just as French and
> Spanish use Latin script. So language detection based on symbol code
> points works only for distinct enough languages. Explicit markup may
> still be necessary to switch hyphenation rules, dash styles, etc.
True. Thanks for pointing it out. Indeed, \babelprovide with the
ochar=id fonts option only makes sense when 1 foreign language = 1
script. For example, different variants of Greek cannot be combined
without an explicit switch.
And something like this wouldn't work either:
\babelprovide[import,onchar=id fonts]{russian}
\babelprovide[import,onchar=id fonts]{bulgarian}
\babelfont[russian]{rm}[Color=blue]{Old Standard}
\babelfont[bulgarian]{rm}[Color=green]{FreeSerif}
because bulgarian overwrites russian.
Well, another added complication :-(.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* [patch] Fix inner smart quotes in French
@ 2023-08-04 7:25 12% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-04 7:25 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
Hi,
These last months I have been disconnected from the list for family
reasons. Now, trying to catch up with the news on the list and pending
things that I left here :-).
In the meantime, I'm submitting this patch with a fix for second-level
French `smart quotes': the correct quotes should be “” (without spaces,
as in Spanish or Greek) (please, some francophone correct me, if I'm
wrong...).
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Attachment #2: 0001-lisp-ox.el-fix-inner-smart-quotes-in-French.patch --]
[-- Type: text/x-patch, Size: 1195 bytes --]
From 202a085ce9e0e3e7c0e67bcdde91e706050fd976 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 4 Aug 2023 09:04:03 +0200
Subject: [PATCH] lisp/ox.el: fix inner smart quotes in French.
* (org-export-smart-quotes-alist): the correct French second level
quotation marks are added.
---
lisp/ox.el | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index 3a6dd8ded..473bd927c 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5840,11 +5840,8 @@ transcoding it."
(primary-closing
:utf-8 " »" :html " »" :latex "\\fg{}"
:texinfo "@tie{}@guillemetright{}")
- (secondary-opening
- :utf-8 "« " :html "« " :latex "\\og "
- :texinfo "@guillemetleft{}@tie{}")
- (secondary-closing :utf-8 " »" :html " »" :latex "\\fg{}"
- :texinfo "@tie{}@guillemetright{}")
+ (secondary-opening :utf-8 "“" :html "“" :latex "``" :texinfo "``")
+ (secondary-closing :utf-8 "”" :html "”" :latex "''" :texinfo "''")
(apostrophe :utf-8 "’" :html "’"))
("is"
(primary-opening
--
2.41.0
^ permalink raw reply related [relevance 12%]
* Re: To avoid zero width space: Re: Experimental public branch for inline special blocks
2024-03-06 18:27 12% ` Juan Manuel Macías
@ 2024-03-06 21:13 12% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-06 21:13 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> However to produce clean export result <span> elements should not be
> added if no attributes are specified. My expectation is
>
> "<p>
> Example of <b>intra</b><i>word</i> markup</p>
> "
With the latest commit now the anonymous variant without attributes
simply returns the content (in LaTeX, HTML and odt). You can try:
&_{/lorem/}&_{*ipsum*}&_{_dolor_}
==> LaTeX: \emph{lorem}\textbf{ipsum}\uline{dolor}
==> HTML <i>lorem</i><b>ipsum</b><span class="underline">dolor</span>
==> ODT <text:span text:style-name="Emphasis">lorem</text:span><text:span text:style-name="Bold">ipsum</text:span><text:span text:style-name="Underline">dolor</text:span>
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: To avoid zero width space: Re: Experimental public branch for inline special blocks
@ 2024-03-06 18:27 12% ` Juan Manuel Macías
2024-03-06 21:13 12% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-06 18:27 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> However to produce clean export result <span> elements should not be
> added if no attributes are specified. My expectation is
>
> "<p>
> Example of <b>intra</b><i>word</i> markup</p>
> "
It seems like a good idea to me. Currently, in LaTeX:
&_{lorem ipsum dolor} ==> LaTeX ==> lorem ipsum dolor
It can also be extended to html, odt and the rest of the backends.
That is, by default, the anonymous variant without attributes simply
returns the content.
Another possibility (with the current implementation):
#+options: inline-special-block-aliases:(("b" :html-tag "b")("i" :html-tag "i"))
&b{intra}&i{word}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: Re [Patch] Pre-/postpend arbitrary LaTeX code to a section
@ 2022-09-20 19:35 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-20 19:35 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List
Ihor Radchenko writes:
>> Can it be extended to add properties to a
>> #BEGIN_example
>> #END_example
>> snippet?
>
> Didn't we conclude that wrapping blocks during LaTeX export should be
> done via special blocks? (This question has been raised multiple times,
> I am unsure if you are referring to the same discussion I have in mind).
Special blocks is usually the best solution for these cases. But
(without wishing to add more fuel to old discussions) I think it would
be nice to have as attr_latex a series of positions similar to the hooks
in the etoolbox LaTeX package:
\AtBeginEnvironment
\AtEndEnvironment
\BeforeBeginEnvironment
\AfterEndEnvironment
Something like :pre :post :precontent :postcontent.
In the case of blocks, I think this would simplify the documents a lot
if what you are looking for makes sense only in LaTeX export (special
blocks are exported to everything).
And in the case of floating objects such as tables or figures, it would
be really useful, since here you cannot resort to the use of special
blocks (*inside* those environments, I mean), and the workarounds that are
usually provided are still a bit tricky.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: [RFC] LaTeX - automatically configure encoding when exporting non-Latin languages
@ 2024-02-02 16:18 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-02 16:18 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List
Ihor Radchenko writes:
> #+LANGUAGE: fa
> #+LaTeX_Header: \usepackage[AUTO]{polyglossia}
>
> #+latex_header: \usepackage[AUTO]{fontspec}
I think Pedro is referring to fontenc not fontspec. fontenc cannot be
used in either lualatex or XelaTeX. fontspec is for advanced selection
of truetype and opentype fonts in XeLatex and LuaLaTeX and setting
opentype properties. fontenc is for 'pre-Unicode' LaTeX font encoding. I
would say that what Pedro proposes is limited only to the output in
pdfTeX.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: caption width in LateX export
@ 2021-12-27 9:09 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-27 9:09 UTC (permalink / raw)
To: Seb; +Cc: orgmode
P.S.: I have come up with another possibility, more automatic, on the
LaTeX side, if you compile with LuaTeX. This thread
(https://tex.stackexchange.com/questions/202046/width-of-the-caption-of-a-figure),
where someone proposes to use a \savebox for concrete images, gave me
the idea. We can automate that through a simple function in Lua, and add
it to the `process_input_buffer' callback, in order to the caption
*always* has the width of each image:
You can put this in your Org document:
#+NAME: luacode
#+begin_src latex :exports none
\usepackage{luacode}
\begin{luacode*}
function caption_width ( text )
text = string.gsub ( text, "(\\includegraphics.+)", "\\sbox0{%1}")
text = string.gsub ( text, "(\\caption{.+})", "\\begin{minipage}{\\wd0}\\usebox0%1\\end{minipage}")
return text
end
\end{luacode*}
\newcommand\CaptionAutoWidth{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , caption_width , "caption_width" )}}
\AtBeginDocument{\CaptionAutoWidth}
#+end_src
#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <<luacode>>
#+end_src
And then:
#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit
#+ATTR_LaTeX: :width .3\linewidth
[[img]]
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> If you use the caption package (https://www.ctan.org/pkg/caption), you
> can indicate in each figure the width of the caption. In this case, you
> would have to introduce the code using raw latex via the `:caption'
> property:
>
> #+LaTeX_Header: \usepackage{caption}
>
> #+ATTR_LaTeX: :caption \captionsetup{width=.3\linewidth}\caption{Lorem ipsum dolor sit amet, consectetuer adipiscing elit}
> #+ATTR_LaTeX: :width .3\linewidth
> [[file_path]]
^ permalink raw reply [relevance 12%]
* Re: "Full Block" character in example block not visible in Beamer PDF
@ 2024-02-12 11:06 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-12 11:06 UTC (permalink / raw)
To: Loris Bennett; +Cc: Org Mode Mailing List
Loris Bennett writes:
> The blocks of the histogram are present in the PDF, but are white, like
> the background of the slides. I can see this by marking them with the
> mouse.
>
> Does anyone know what I need to do to make the full block character
> visible in this situation?
Do you compile your document with pdfLaTeX?
It looks like you're using a Unicode character (FULL BLOCK / #2588 /
descomp: █ #2588) that pdfLaTeX doesn't recognize. You would have to use
LuaTeX or XeTeX as a TeX engine. And load the fontspec package to manage
the ttf or otf fonts. Additionally, you must define a mono font that
contains that character, for example Ubuntu Mono. An example:
#+TITLE: Some title
#+AUTHOR: author
#+Beamer_Header:\usepackage{fontspec}
#+Beamer_Header:\setsansfont{Linux Biolinum O}
#+Beamer_Header:\setmonofont{Ubuntu Mono}
#+LATEX_CLASS: beamer
#+LATEX_CLASS_OPTIONS: [presentation]
#+BEAMER_THEME: Boadilla
#+COLUMNS: %45ITEM %10BEAMER_ENV(Env) %10BEAMER_ACT(Act) %4BEAMER_COL(Col)
Screenshot:
https://i.imgur.com/ulYxJgr.png
Bonus: To check which fonts on your system contain a certain character,
you can use the TeX live tool Albatross. E.g.:
albatross █ --border-style 0 --detailed --show-styles --include-tex-fonts
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-22 14:07 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-22 14:07 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Juan Manuel Macías writes:
> OK, so why not just:
>
> #+latex_header: % NOLANG
>
> ?
Forget this. On second thought, I think that the option you proposed
"#+LaTeX_Header: % \usepackage{babel}" is much better.
(I don't know where my head was and I didn't remember there was a
string-match, so your suggestion is the shortest way. However, the line
would have to be (with arguments):
#+LaTeX_Header: % \usepackage[something]{babel}
or
#+LaTeX_Header: % \usepackage[something]{polyglossia}
or modify the regexp in org-latex-guess-babel/polyglossia-language.
^ permalink raw reply [relevance 12%]
* Re: [patch] Add two new header args to LaTeX block
@ 2024-02-10 15:20 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10 15:20 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> The attached patch adds two new header args to the LaTeX block:
>>
>> - `:pdf-process' allows modifying the value of `org-latex-pdf-process'
>> locally to the block. This can be useful for evaluating a given block
>> with another LaTeX compiler, or even using some custom script.
>> Example:
>> ...
>> - `:full-to-pdf' makes the block like a standalone LaTeX document, which
>> should contain everything needed to be compiled, from \documentclass{}
>> to \end{document}. Example:
>
> Thanks!
> May you please explain in more detail how these new header arguments fit
> into other available LaTeX code block parameters? In particular, when
> exporting to .png/.svg/.html or when :imagemagick header argument is provided.
Sure! `:pdf-process' simply applies a local value to
org-latex-pdf-process. It does not affect the export to png in its
version without imagemagick process, since this option depends on
org-create-formula-image, which in turn depends on
org-preview-latex-default-process. It also does not affect the export to
html, which depends on org-babel-latex-htlatex. It should work in all
other cases, including imagemagick, which ultimately depend on
org-latex-pdf-process.
As for `:full-to-pdf' (I don't know if standalone-to-pdf would be a
better name), the expected result is a pdf file. Therefore it is
incompatible with exporting to png, svg or conversion with imagemagick.
For it to work, it is enough to provide these 2 args: ":file foo.pdf
:full-to-pdf yes."
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: [patch] Add two new header args to LaTeX block
@ 2024-02-10 17:48 12% ` Juan Manuel Macías
2024-02-10 19:35 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10 17:48 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> May you please explain in more detail how these new header arguments fit
>>> into other available LaTeX code block parameters? In particular, when
>>> exporting to .png/.svg/.html or when :imagemagick header argument is provided.
>>
>> Sure! `:pdf-process' simply applies a local value to
>> org-latex-pdf-process. It does not affect the export to png in its
>> version without imagemagick process, since this option depends on
>> org-create-formula-image, which in turn depends on
>> org-preview-latex-default-process. It also does not affect the export to
>> html, which depends on org-babel-latex-htlatex. It should work in all
>> other cases, including imagemagick, which ultimately depend on
>> org-latex-pdf-process.
>
> Would it make sense to make :pdf-process work for png previews as well?
It would be ideal. The expected value for org-latex-pdf-process is a
command or a list of commands, but org-preview-latex-default-process
expects a plist of various processes and parameters. Maybe with some
conditional? If only the png extension is provided (without the
:imagemagick argument), then the expected value is for
org-preview-latex-default-process. In all other cases, the value is for
org-latex-pdf-process. The argument could then be called simply
:process. E.g.:
Assuming the user has somewhere (add-to-list
org-preview-latex-process-alist my-process):
:results file :file foo.png :process 'my-process [or :process '(a plist)]
In other cases, like this:
:imagemagick yes :results file :file foo.png :process '("lualatex -interaction nonstopmode -output-directory %o %f")
wdyt?
>> As for `:full-to-pdf' (I don't know if standalone-to-pdf would be a
>> better name), the expected result is a pdf file. Therefore it is
>> incompatible with exporting to png, svg or conversion with imagemagick.
>> For it to work, it is enough to provide these 2 args: ":file foo.pdf
>> :full-to-pdf yes."
>
> Maybe just :standalone?
Yes, I totally agree.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: Footnotes on line and not raised
@ 2024-03-11 11:03 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-11 11:03 UTC (permalink / raw)
To: Colin Baxter; +Cc: emacs-orgmode
Colin Baxter writes:
> Perhaps it's not possible because I see that .footref in css support is
> always <sup>.
You can modify <sup> a little so that it does not alter the paragraph
line spacing so much. In this example, with a value of 0em, it is
positioned on the baseline:
#+HTML_HEAD: <style> sup {vertical-align: baseline;position: relative;bottom: 0em;} </style>
Another slightly dirtier way is with an export filter in your document.
The sub tag is removed and the reference number is enclosed in square
brackets, separated by a space from the previous word:
#+BIND: org-export-filter-footnote-reference-functions (footnote-sup-filter)
#+begin_src emacs-lisp :exports results :results none
(defun footnote-sup-filter (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "<a" " <a"
(replace-regexp-in-string "\\([[:digit:]]+\\)\\(</a\\)" "[\\1]\\2"
(replace-regexp-in-string "</?sup>" "" text)))))
#+end_src
screenshot:
https://i.ibb.co/CBRnfXG/pantallazo-79248380551244229p8.png
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: [proof of concept] inline language blocks
@ 2024-02-21 14:13 12% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-21 14:13 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> We need to finalize inline special block syntax first, and then talk
>>> about special cases like inline language markup you propose.
>>
>> As I already said, in my local branch I have both elements created,
>> based on the same syntax:
>>
>> - language block: :lang{text}
>>
>> - special block &type{text}
>>
>> the latter would be exported, for example, to html as <span class="type">text</span> or to LaTeX as \type{text}
>>
>> I like the syntax because it is minimalist and not verbose at all. That
>> could serve as a basis (at least it is good to have a starting point,
>> because otherwise everything will be diluted in discussions). Then we
>> can start thinking about whether to add options and how to add them.
>
> We do not need to design the inline special block markup fully to
> introduce it. However, we do need to make sure that whatever simple
> version of inline markup we introduce does not prevent further planned
> extensions.
My proposed syntax could be:
&type[options]{content}
> My main concern is the possibility to introduce multi-argument markup.
> Like @abbrev{EA}{example abbreviation}. This will be necessary to
> achieve parity with Texinfo markup.
> However, it is not yet clear about the best syntax to pass multiple
> arguments.
I imagine multiple arguments would depend on each backend, right?
Because I don't quite see much sense in html, for example. However, it
occurs to me to reuse content, and add some separator character:
&type[options]{arg1::arg2::etc}
or better:
&type[options and aditional args]{content}
to maintain a certain parallelism with the large blocks.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
@ 2024-03-15 16:26 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-15 16:26 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> (ignore
> (pp
> (let ((rules
> (org-export--inline-special-block-make-backend-alist
> (org-split-string "latex/ html./ ascii+ *"))))
> (mapcar (lambda (backend)
> (list backend
> (org-export--inline-special-block-export-decision
> rules backend)))
> '(odt latex beamer html md ascii)))))
>
> Gives
>
> ((odt content)
> (latex nil)
> (beamer nil)
> (html nil)
> (md content)
> (ascii full))
>
> Function definitions:
>
> (defun org-export--inline-special-block-make-backend-alist
> (rules)
> (nconc
> (let (result)
> (dolist (spec rules)
> (if (string-match
>
> "\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
> spec)
> (let ((name (match-string 1 spec))
> (inherit (match-string 3 spec))
> (what (or (match-string 2 spec)
> (match-string 4 spec))))
> (push (cons
> (if (string-equal "" name) '@ (intern name))
> (cons (or (not inherit) (string-equal inherit "="))
> (if what (string-to-char what) ?+)))
> result))
> (message "invalid :export specification %S" spec)))
> result)))
>
> (defun org-export--inline-special-block-export-decision
> (rules-alist backend)
> (when (symbolp backend)
> (setq backend (org-export-get-backend backend)))
> (let* ((rule (assoc (org-export-backend-name backend) rules-alist))
> (decision (and rule (cddr rule))))
> (while (and (not decision)
> (setq backend (org-export-backend-parent backend)))
> (setq backend (org-export-get-backend backend))
> (when (and (setq rule (assq (org-export-backend-name backend)
> rules-alist))
> rule
> (cadr rule))
> (setq decision (cddr rule))))
> (unless decision
> (setq rule (assq '@ rules-alist))
> (setq decision (and rule (cddr rule))))
> (pcase decision
> (?+ 'full)
> (?* 'content)
> (?/ nil)
> (_ 'full))))
I've been testing your code and it works very well. It is certainly
finer than the current approach. I think it could be implemented, and we
are testing that.
Tomorrow I will make a new commit with your code.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
@ 2024-03-12 17:41 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-12 17:41 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> It is not clear for me how to achieve the following. Add a link
>
> [[https://youtube.com/...][Org mode in action demo (video)]]
>
> for all backends (EPUB, LaTeX, ODT, text, etc.) besides HTML because
> there is an #+export_html block with player embedded using an iframe.
Sorry, I don't quite understand this. Could you please elaborate?
> Instead of "noexport" and "rest" that may be confused with backend
> names I would consider "+" and "*" without any name. I would consider
> some characters like "-", "_", "!", "~" to express "do not export to
> this and derived backends" and "do not export for specified backend
> only".
how about the following:
- "--" :: do not export
- "**" :: export only the content
- "==" :: rest (full)
- "=*" :: rest (only the content)
- "!backend-name+ :: export this backend (full)
- "!backend-name*" :: export this backend (only the content)
- "!backend-name- :: do not export this backend
?
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
@ 2024-03-09 11:48 12% ` Juan Manuel Macías
2024-03-09 15:24 14% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-09 11:48 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> However it is still gives
>
> (org-export-string-as "Alpha@Beta["
> 'html
> '(:export-options (body-only)))
> Debugger entered--Lisp error: (wrong-type-argument
> number-or-marker-p nil)
I think the problem is the contents-begin variable. When it is nil it
produces that error. I will make a new commit to fix the bug.
Thanks for all the tests you're doing!
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
@ 2024-03-08 18:44 12% ` Juan Manuel Macías
2024-03-08 18:57 14% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-08 18:44 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> Debugger entered--Lisp error: (wrong-type-argument
>>> number-or-marker-p nil)
>>
>> Maybe in that case you could add a zero width space character.
>>
>> In any case, if someone has reasons to write "Alpha@Beta{" they may also
>> have reasons to write "Alpha_Beta":
>
> 1. Parser must not throw errors on text files. Ever. Any text file is a
> valid Org file.
> 2. We should demand paired {...}, as we do for latex fragments,
> emphasis, inline export snippets, and all other container objects.
Ok, I think you and Maxim are right. This is a clear bug. I hope it
was fixed in the last commit.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
@ 2024-03-08 15:44 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-08 15:44 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> (org-export-string-as "Alpha@Beta{"
> 'html
> '(:export-options (body-only)))
> "<p>\nAlpha<span class=\"Beta\"></span>{</p>\n"
>
> (org-export-string-as "Alpha@Beta["
> 'html
> '(:export-options (body-only)))
> Debugger entered--Lisp error: (wrong-type-argument
> number-or-marker-p nil)
Maybe in that case you could add a zero width space character.
In any case, if someone has reasons to write "Alpha@Beta{" they may also
have reasons to write "Alpha_Beta":
(org-export-string-as "Alpha_beta"
'html
'(:export-options (body-only)))
<p>
Alpha<sub>beta</sub></p>
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-07 16:57 12% ` Juan Manuel Macías
@ 2024-03-07 18:21 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-07 18:21 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías writes:
> Ihor Radchenko <yantar92@posteo.net> escribió:
>
>> I am wondering if @@[...]{...} would be better than @_...
>> It should be slightly easier to type.
>
> Another possibility would be @:[...]{...}, which is somewhat shorter.
>
> (I don't have any special preference, although @@ visually reminds me a
> bit of the export snippet).
Anyway, in the last commit I replaced _ with @. Let's see how it goes...
Now the anonymous variant is @@[...]{...}.
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
@ 2024-03-07 16:57 12% ` Juan Manuel Macías
2024-03-07 18:21 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-07 16:57 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko <yantar92@posteo.net> escribió:
> I am wondering if @@[...]{...} would be better than @_...
> It should be slightly easier to type.
Another possibility would be @:[...]{...}, which is somewhat shorter.
(I don't have any special preference, although @@ visually reminds me a
bit of the export snippet).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
@ 2024-03-07 15:53 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-07 15:53 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> I suggest @type[...]{...}. Akin Texinfo constructs.
>
> (Texinfo because of
> previous RMS' request to implement better support for markup used in
> software manuals - keeping things close to Texinfo syntax will make life
> easier if we ever reach the point when Org mode is used as standard
> documentation format.)
I have modified the syntax in the last commit. Now:
@type[...]{...} (or @_[...]{...})
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
@ 2024-03-07 11:06 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-07 11:06 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> It seems the parser finds new objects where syntactical constructs are
> incomplete:
>
> (org-export-string-as "Alpha&Beta{"
> 'html
> '(:export-options (body-only)))
> "<p>\nAlpha<span class=\"Beta\"></span>{</p>\n"
mmm, right. And there may also be a problem with the subscripts: &_{subscript}...
Perhaps we should think about a structure less prone to ambiguities. For
example:
&:type[attrs]{text} / &:_[attrs]{text}
(I think someone had suggested something like this in a past message,
but I can't find it, apologies).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: naming: Re: Experimental public branch for inline special blocks
@ 2024-03-04 17:49 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-04 17:49 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Max Nikulin <manikulin@gmail.com> writes:
>
>> Does anybody have an idea of a better name for a feature? Maybe
>> something like inline custom objects, snippets. "Objects" are used to
>> describe syntax, but not used in the manual though.
>
> Custom inline markup.
Custom span?
I chose "inline special block" because special blocks, and because of
the parallelism inline code block/code block.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: [proof of concept] inline-special-block
2024-02-22 22:03 13% ` [proof of concept] inline-special-block Juan Manuel Macías
@ 2024-02-21 23:29 12% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-21 23:29 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> Syntax:
>
> &[optional parameters]{contents}
Correction:
&type[optional parameters]{contents}
^ permalink raw reply [relevance 12%]
* Re: [patch] Add two new header args to LaTeX block
@ 2024-02-19 13:24 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-19 13:24 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> I'd prefer to refactor `org-babel-execute:latex' first, before adding
>>> new header arguments.
>>
>> org-create-formula-image inserts LaTeX code:
>
> `org-create-formula-image' will be obsoleted after Timothy merges his
> latex preview branch. If the new implementation turns out to be not
> flexible enough, we can always refactor it further to meet ob-latex
> needs.
In that case, I think this patch could be considered canceled.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
@ 2023-10-01 18:07 12% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-01 18:07 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> Since the header arg :float now supports any string in inline images[...]
Sorry, I meant "the LaTeX attribute :float ..."
^ permalink raw reply [relevance 12%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
@ 2023-09-09 10:36 12% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-09 10:36 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode, Max Nikulin
Ihor Radchenko writes:
>> I don't know if it's a valid path to allow the car of each element to
>> also be a list of languages codes, but I couldn't think of a better
>> solution for the "de"/"de-de" cases. A similar case is in Chinese
>> Simplified (new language added), where the possible language codes are
>> zh and zh-cn, if I'm not wrong.
>
> I am not sure if making a breaking change to public constant is the best
> approach.
> What about simply adding an extra entry:
> ("de" ....)
> ("de-de" <copy of "de" property list>)
> ?
At first I had done it with extra entries, but I was wondering if there
wasn't a more "economical" way... If you don't mind having extra entries
with identical plists, then I do it that way. After all, there are only
two cases (Chinese and German).
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
@ 2023-09-07 14:19 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-07 14:19 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
>> In both lists the language code for German is simply "de". Of course,
>> I'm no expert on the subject, so if I'm wrong in this case, I should
>> revert the change. I understand that de-de is German of Germany (="de"?); on
>> org-latex-language-alist exists de-at (Austrian German). The babel ini
>> file for german babel/locale/de/babel-de.ini has this id:
>
> I understand the motivation, but the end result is a clear regression.
> May you please review 97cfb959d and recover the removed language names
> to put into #+language as aliases to their correct names?
I think I can introduce some fixes to org-latex-language-alist to
restore the removed language codes, without breaking the new and
maintaining compatibility with the old. As soon as I have some time I
will send a patch. Probably this weekend.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
@ 2023-08-09 8:41 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-09 8:41 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>>> I see nothing that would prevent merging this patch.
>>> However, I believe that removing blank lines before/after content is
>>> something we may want to do in other built-in backends as well. WDYT?
>>
>> I think you're right. My impression is that the blank lines before/after
>> content is not a desired feature, but rather a consequence of
>> substituting line breaks to create the space between stanzas.
>
> Do you mean that people use extra leading/trailing spaces just to get
> extra vertical space before/after the verse block in _latex_ export?
No, I don't think people use it for that purpose. I meant that if
someone puts a space before or after the content (which can be usual,
for clarity):
#+begin_verse
blah...
#+end_verse
that vertical space appears in the export, which shouldn't.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: Help with a (query) replacement
@ 2022-11-12 15:23 12% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-12 15:23 UTC (permalink / raw)
To: Ypo; +Cc: Org-mode
Juan Manuel Macías writes:
> I think it will be more practical for you to use pandoc:
>
> With this command you can convert an epub format to org:
>
> pandoc my-epub.epub -o my.epub.org
>
> (https://pandoc.org)
>
> You can also install calibre and convert your epubs to plain text from
> there.
PS: And you can also open epubs in Emacs with the nov.el package
(https://github.com/wasamasa/nov.el) and copy whatever text you want
from there.
^ permalink raw reply [relevance 12%]
* Re: [off-topic] E-readers and Org-Mode
@ 2022-10-29 9:03 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-29 9:03 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> [...] Anyway, I think it would be possible to write some python
> script[1] to extract the annotations and then parse the resulting xml
> from there to get a nice and beautiful Org document. Which also leads
> me to wonder if anyone has tried that.
I've found that org-noter has the `org-noter-create-skeleton' function,
which exports PDF annotations to Org and keeps them in sync with the PDF
(via pdf-tools). Tremendously useful! :-)
^ permalink raw reply [relevance 12%]
* Re: Line breaks and brackets in LaTeX export
@ 2022-10-19 12:30 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-19 12:30 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Juan Manuel Macías writes:
>> For a while I have the following question. Is \\{} have the same
>> effect on tabularray parser as \\\empty?
>
> Throw an error before \hline.
To expand on my answer: \\{} and \\\empty, before \hline, throw the same
error:
------------------------------
ERROR: Misplaced \noalign.
--- TeX said ---
\hline ->\noalign
{\ifnum 0=`}\fi \hrule \@height \arrayrulewidth \futurelet...
l.17 \end
{tblr}
--- HELP ---
From the .log file...
I expect to see \noalign only after the \cr of
an alignment. Proceed, and I'll ignore this case.
------------------------------
^ permalink raw reply [relevance 12%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
@ 2022-07-11 12:04 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-11 12:04 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> By the way, although I've already commented on it in some post in the
> parent thread, i think this package I wrote might be useful for doing a
> quick visual test of a font (including opentype features test), using
> org-latex-preview (compiling with LuaTeX). It can be done on any font
> marked in dired. There are three options: insert arbitrary characters,
> insert the Unicode code of the characters, or display a specimen of the
> font. The default specimen is in the file specimen.tex, which can be
> edited to add examples and languages.
>
> Some screenshots:
>
> https://i.imgur.com/3faKSjA.png
>
> https://i.imgur.com/OJfUcO9.png
Sorry, I forgot the link:
https://gitlab.com/maciaschain/org-font-spec-preview
^ permalink raw reply [relevance 12%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
@ 2022-07-10 20:31 12% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-10 20:31 UTC (permalink / raw)
To: orgmode
Sorry, I forgot to add quotes :-) "\\usepackage{iftex}...\\fi"
Juan Manuel Macías writes:
> (format
> \\usepackage{iftex}
> \\ifpdftex
> \\relax
> \\else
> \\usepackage{fontspec}
> \\usepackage{unicode-math}
> \\defaultfontfeatures{Scale=MatchLowercase}
> \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
> \\setmainfont{%s}
> \\setsansfont{%s}
> \\setmonofont{%s}
> \\fi
> org-latex-fontspec-mainfont
> org-latex-fontspec-sansfont
> org-latex-fontspec-monofont)
^ 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
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: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-19 11:08 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-19 11:08 UTC (permalink / raw)
To: tomas; +Cc: orgmode
* sorry for the typo. I meant "...n columns x n rows..."
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Anyway, I suspect that Org tables are not originally intended for such a
> 'literary' content :-) ... LaTeX tabular(x) environment and Org tables
> have in common that they are plain text, but that’s where the
> similarities end. Org tables are visual (close to the WYSIWYG concept),
> which is why they are wonderful when it comes to mere data tables (and n
> files x n rows). The LaTeX tabular environment is crude, it is not
> 'visual' (except for the facilities provided by the editor), and when
> the table becomes large and complex it can be a torture working in
> there... So perhaps (IMHO) the solution to edit a cell in a dedicated
> buffer could be the least traumatic in complex cells, in case one wants
> to avoid going crazy by editing this kind of huge and literary tables in
> LaTeX ;-)
^ permalink raw reply [relevance 12%]
* Making a dictionary in Org
@ 2021-12-08 20:03 12% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-08 20:03 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
Hi,
How to create a 'dictionary style' PDF document from Org, with two
columns and with dynamic page headers[1]: here I share (attached) an Org
file, in case it is useful to someone, with the (simplified) LaTeX code
I used to define the styles of the entries and the dynamic page headers
in the typesetting of the /Hispanic Dictionary of Classical Tradition/.
I produced this dictionary (828 pp.) using Org and Org-Publish, with
output to LuaLaTeX. Some images:
https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc5.png
https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc3.png
https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc4.png
[1] If a page contains multiple entries, the first and the last entries
are collected, both separated by an en dash; if the page contains a
single entry, or a continuation of the previous page/entry, it is
collected that entry only.
Best regards,
Juan Manuel
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
[-- Attachment #2: dictionary.org --]
[-- Type: application/vnd.lotus-organizer, Size: 1218 bytes --]
^ permalink raw reply [relevance 12%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
@ 2023-09-21 21:19 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-21 21:19 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> I also tried with:
>
> (setq org-latex-pdf-process
> (if (executable-find "latexmk")
> '("latexmk -interaction nonstopmode -output-directory %o
> %f")
> "bibtex %b"
> '("%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"))
I think the expression is bad formed; In addition, latexmk is already
responsible for executing bibtex or biber and other processes that
require more than one compilation. The right thing would be:
(setq org-latex-pdf-process (if (executable-find "latexmk")
'("latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f")
'("%latex -interaction nonstopmode -output-directory %o %f"
"%latex -interaction nonstopmode -output-directory %o %f"
"%latex -interaction nonstopmode
-output-directory %o %f")))
(or just remove the customization of that variable from your init).
And then put in your document:
#+LATEX_COMPILER: lualatex (or pdflatex or xelatex)
This keyword modifies the value of org-latex-compiler in the document.
If you are going to use lualatex more often, you can put in your init:
(setq org-latex-compiler "lualatex")
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: org exported pdf files
@ 2022-09-28 18:23 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-28 18:23 UTC (permalink / raw)
To: Tim Cross; +Cc: Timothy, Jude DaShiell, Ihor Radchenko, emacs-orgmode
Hi, Tim
Tim Cross writes:
> An unfortunate situation really - especially given Emacs has one of the
> most powerful and advanced accessibility options available via
> emacspeak.
>
> I also won't hold my breath for a new latgex core. THe latex3 initiative
> seems to have failed or at least appears to be slower to be realised than perl6!
You may find this article by Frank Mittelbach from 2020 interesting,
about the future of LaTeX and the challenges to be solved, including the
accessibility issues:
https://www.latex-project.org/publications/2020-FMi-TUB-tb128mitt-quovadis.pdf
On the other hand, there is also ConTeXt. I don't know much about
ConTeXt, but I remember reading somewhere that ConTeXt is more mature
than LaTeX on PDF tagging and accessibility issues. I don't know if
there are any ConTeXt experts on the list who can confirm this... In any
case, an ox-context already exists for org, written by Jason Ross.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: [BUG] Footnotes in section titles
@ 2024-01-24 15:23 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-24 15:23 UTC (permalink / raw)
To: Max Nikulin; +Cc: Eric Anderson, ihor Timothy, Ihor Radchenko, orgmode
Max Nikulin writes:
> I recall some tricks with \footnotemark and \footnotetext, but I do
> not remember details and whether it may work for section titles.
> Complications may arise if a heading title has several footnotes.
ox-latex has 'org-latex--delayed-footnotes-definitions': "[...] This
function is used within constructs that don't support \footnote{}
command (e.g., an item tag). In that case, \footnotemark is used within
the construct and the function just outside of it."
The \footnotetext/\footnotemark option works well for specific cases,
but in general I don't like to abuse this method.
> Perhaps it is better to avoid footnotes in titles and to add some
> phrase to the body instead.
That is the ideal scenario. I also believe that footnotes should be
avoided in section headings, if possible. Or at least, have another type
of numbering (symbols, letters...). The manyfoot and bigfoot packages
allow constructions of this type, with various footnote apparatus.
Best regards,
Juan Manuel
--
Juan Manuel Macías --
^ permalink raw reply [relevance 12%]
* Re: Retaking AUTO for \usepackage{fontenc}
@ 2024-02-13 11:57 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-13 11:57 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List
Pedro Andres Aranda Gutierrez writes:
> Hi,
>
> Next step, @all, please help me filling up the list of codings vs.
> languages. I currently am somehow confident of the following:
>
> greek -> LGR
> russian -> T2A
The information is in the encguide PDF (you can run texdoc fontenc or
texdoc encguide). You should look especially at section 2.3 256 glyph
encodings. I don't know if some languages require more than one
encoding. Cyrillic appears to be T2A, T2B and T2C. T4 is for
"The African Latin fonts contain in their lower half (0–127) the same
characters as the European Latin (T1-encoded) Fonts, while in their
upper half (128–255) they contain letters and symbols for African
languages that use extended Latin alphabets."
etc.
But I can't find a simpler list anywhere.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
@ 2023-09-21 8:24 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-21 8:24 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Hi,
I would recommend that you use babel, as it is the official package for
language support and now has many more options than polyglossia. You can
try this preamble (compiles in LuaLaTeX):
\documentclass{article}
\usepackage[english]{babel}
\usepackage{fontspec}
\newfontscript{Devanagari}{deva}
\babelprovide[onchar=ids fonts]{sanskrit-devanagari}
\babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
With \babelprovide... there is no need to add a \selectlanguage or other
similar command. The problem with your example is that you need to put a
command to select the language before the Devanagari text, like
\selectlanguage{sanskrit}
Best regards,
Juan Manuel
Zenny <garbytrash@gmail.com> escribió:
> Hi,
>
> I tried to export to pdf with the following:
>
> #+LATEX_HEADER: \usepackage{polyglossia}
> #+LATEX_HEADER: \usepackage{fontspec}
> #+LATEX_COMPILER: xelatex (also tried with lualatex)
> #+LATEX_HEADER: \setmainlanguage{english}
> #+LATEX_HEADER: \setotherlanguage{sanskrit}
> #+LATEX_HEADER: \newfontfamily\devanagarifont{Noto Serif
> Devanagari}
>
> स्वस्ति सत्यं वचति
>
> but it exports alright to odt, and even pandoc exports alright
> directly from org file to docx file, but the Sanskrit/Devanagari fonts
> are skipped (blank) in pdf output when exported directly from org file
> with C-c C-e l o.
>
> Already tried with the solutions provided in
> https://emacs.stackexchange.com/questions/27576/exporting-devanagarai-text-from-org-mode-to-latex,
> but there are no such options (variables defined) after 'M-x
> customize-group' available.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Fancy underlines in Org to LaTeX
@ 2021-10-20 14:57 13% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-20 14:57 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
Hi,
A very interesting LaTeX package, soulpos (by Javier Bezos), has
recently been uploaded to CTAN, which allows you to define personalized
underlining styles in a very free way:
https://www.ctan.org/pkg/soulpos
I have tried to adapt its use to Org, so I am attaching a small test
document here. In the preamble I have defined a command \myuline (with
the xparse syntax), with five different values for \uline:
- \myuline the default value, a single underline,
- \myuline[ul1], \myuline[ul2], \myuline[ul3] and \myuline[ul4], four
different underline styles, taken from the examples in the soulpos
documentation.
See this screenshot: https://i.imgur.com/UK6W8sl.png
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
[-- Attachment #2: soulpos-test.org --]
[-- Type: application/vnd.lotus-organizer, Size: 4018 bytes --]
^ permalink raw reply [relevance 13%]
* org-verse-num: display verse numbers within a verse block
@ 2022-08-07 12:53 13% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-08-07 12:53 UTC (permalink / raw)
To: orgmode; +Cc: emacs-humanities
Hi all,
I've added some minor improvements to my little package 'org-verse-num',
which was born out of necessity in my translation to spanish
(work-in-progress) of Homer's Odyssey (11600 verses spread over 24
books):
https://gitlab.com/maciaschain/org-verse-num
org-verse-num includes some functions and a minor mode to aid in
navigating through (very) long poems within an Org-mode verse block. It
displays verse numbers sequentially (avoiding empty lines between
stanzas) and you can also move the cursor to a specific verse number.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: Interest in an Org video meetup?
@ 2022-10-07 10:37 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-07 10:37 UTC (permalink / raw)
To: Russell Adams; +Cc: orgmode, Ihor Radchenko
Russell Adams writes:
>> Even if there is a recording, where can we publish the recorded videos?
>
> Exactly.
>
> Recording brings with it extra logistics, which is why I deferred the
> issue. ;]
I was just asking, out of curiosity, if it was planned to be published.
I really don't know where it could be published. I know PeerTube exists,
but I don't know how it works.
There is the YouTube option, which I imagine no one would like (me
neither). The only thing in its favor is that Invidious can be used to
watch the videos. BTW, I watch YT videos through Invidious in Emacs,
with the Ytel package and EMMS/MPV.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
@ 2022-09-21 14:51 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-21 14:51 UTC (permalink / raw)
To: Daniel Fleischer; +Cc: Ihor Radchenko, orgmode
Daniel Fleischer writes:
> I don't understand the usecase, that's why I wasn't really following. If
> you write \vspace{10cm} before some headline, it's going to do the right
> thing even if it "belongs" to a previous headline.
Imagine, for example, that you have defined a LaTeX command that changes
the style of the section (or chapter, subsection, or whatever) below.
And you want to apply it before a certain section. If for any reason you
comment out the preceding section, or mark it as non-exportable, or even
delete it, the preceding command is no longer there when you export to
LaTeX. That would also happen if you move the section.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* org-critical-edition (new version)
@ 2021-11-21 15:36 13% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-21 15:36 UTC (permalink / raw)
To: orgmode
Hi all,
For philologists who might be interested, I have uploaded a new version
of my package `org-critical-edition', with some new features, such as the
ability to use multi-level nested critical notes:
https://gitlab.com/maciaschain/org-critical-edition
It occurred to me to write org-critical-edition as a sort of org-centric
alternative to TEI-XML for the semantic markup of literary texts. My
idea is for a more scholar-friendly, human-readable tool.
Here's a screenshot of a LaTeX/reledmac export sample:
https://i.imgur.com/S9MXzIA.png
Feedback welcome.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 13%]
* Re: [proof of concept] inline-special-block
@ 2024-02-22 22:03 13% ` Juan Manuel Macías
2024-02-21 23:29 12% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-22 22:03 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> Regarding the "optional parameters", there is nothing defined, although
> I think they should be adapted to each backend. A possible use that
> occurs to me:
>
> &foo[prelatex: [lorem] postlatex: {ipsum} html: style="color:red;"]{blah blah}
>
> This should produce in LaTeX:
>
> \foo[lorem]{blah blah}{ipsum}
>
> and in HTML:
>
> <span class="foo" style="color:red;">blah blah</span>
Just to add some more ideas about parameters, I can also think of an
"anonymous" variant that only supports "universal" arguments, independent of
the backend and previously defined (and extensible by the user). For
example:
&_[:color red :smallcaps t :lang it :size small]{Lorem ipsum dolor}
Aliases could also be defined for a set of arguments:
#+OPTIONS: inlineblocks:(("myblock" :smallcaps t :color "red" :lang "fr"))
&_[:myblock t]{Lorem ipsum dolor} etc.
==> latex: {\color{red}\scshape\foreignlanguage{french}{Lorem ipsum dolor}}
Universal arguments can also be added to a normal block along with each
backend's own arguments:
&foo[:color red :prelatex [bar]]{lorem ipsum dolor}
==> latex: {\color{red}\foo[bar]{lorem ipsum dolor}}
and, of course, aliases could be combined with single arguments:
&foo[:myblock t :prelatex [bar]]{lorem ipsum dolor}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: Items with emphasis marks are not sorted properly in a list
2021-03-22 21:59 10% Items with emphasis marks are not sorted properly in a list Juan Manuel Macías
@ 2021-03-23 8:36 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-23 8:36 UTC (permalink / raw)
To: orgmode
Hello again:
I think I have found where the problem is. On line 7 of
`org-sort-remove-invisible' there are two spurious spaces (in the `format'
expression):
7 org-emph-re (lambda (m) (format " %s " (match-string 4 m)))
When the spaces are removed, then the items with emphasis marks are
sorted correctly in the list:
7 org-emph-re (lambda (m) (format "%s" (match-string 4 m)))
Can this be a fix? Or were those spaces there for any other reason?
Best regards,
Juan Manuel
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi,
>
> Consider this list:
>
> - vol.
> - adj.
> - /circa/
> - /vid./
>
> If I evaluate `(org-sort-list t ?a)', it seems that `org-sort-list'
> doesn't sort correctly items that contain an emphasis mark:
>
> - /circa/
> - /vid./
> - adj.
> - vol.
>
> I don't know if there is any solution to this, or if I'm doing something wrong...
>
> Best regards,
>
> Juan Manuel
>
^ permalink raw reply [relevance 13%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
@ 2024-03-10 13:54 13% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-10 13:54 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> I'm thinking about adding a new global attribute, `:export', that
> would granularly control whether or not to export the object and how to
> export it.
>
> Possible values: "noexport", "contents" (it would export only the content)
> or the backends to which you want to export, separated by spaces. Each
> backend should be followed by a "+" sign (= export all) or "*" (export
> content only). For example:
>
> @foo[:color red :export latex+ odt* html*]{lorem ipsum dolor}
>
> This means that "lorem ipsum dolor" would be exported with color format
> to LaTeX, but only the content would be exported to odt and html.
I have implemented the new :export attribute in the last commit, to
experiment (in any case, it can always be reverted). The syntax and
usage are as described in the previous message. An example, where we
define an alias for inline comments and another for highlighted text: It
will only be exported as highlighted text to LaTeX (using the lua-ul
package for LuaLaTeX); only the content will be exported to HTML; and it
will not be exported to the rest of the backends.
#+options: inline-special-block-aliases:(("comment" :export "noexport")("hl" :export "latex+ html*" :latex-command "highLight"))
#+latex_header: \usepackage{xcolor,luacolor,lua-ul}
#+latex_compiler: lualatex
@hl{this is highlighted text, only in LaTeX} @comment{this is a comment}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: [proof of concept] inline language blocks
@ 2024-02-21 22:28 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-21 22:28 UTC (permalink / raw)
To: Samuel Wales; +Cc: Ihor Radchenko, orgmode
Samuel Wales writes:
> for language feature, there are various options here which range from e.g.
>
> :fr{some text in French}
>
> being expressed as
>
> $[lang :fr "bonjour"]
Thanks for your interesting comment. However, your example still seems
too verbose to me. There are two elements that, in my opinion, get in
the way: 'lang' and "bonjour" quotes. Imagine something like this for
emphasis (mutatis mutandis):
$[emphasis :italic "text in italic"]
instead of
/text in italic/.
That simplicity is what I intend to look for with this type of elements
inside the paragraph.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals
@ 2022-10-02 13:47 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-02 13:47 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Fraga, Eric, Max Nikulin, emacs-orgmode@gnu.org
Ihor Radchenko writes:
> _name{<contents>}
> _name{{<contents>}} <--- extra {} is added as needed for escaping
> _name[:key value ...]{<contents>}
>
> The syntax idea is to follow the relevance between [[links]] and [cite:citations]
> but here we have src_name[...]{...} and _name[...]{<contents>} instead.
And how about this:
%_name{<contents>}
%_name{{<contents>}} <--- extra {} is added as needed for escaping
%_name[:key value ...]{<contents>}
or any other symbol instead of "%" ?
N.B.: I must admit this is more for an "aesthetic" reason. Although
perhaps it can be useful to search in the documents.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: org-verse-num: display verse numbers within a verse block
@ 2022-08-07 14:22 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-07 14:22 UTC (permalink / raw)
To: m43cap; +Cc: orgmode, Ihor Radchenko
Colin Baxter writes:
> Your site tells me to turn JavaScript, enable Cookies and complete a
> CAPTCHA, all of which I refuse to do.
>
> Do you have an alternative web-site?
Sorry for the inconvenience. I plan to set up my own GitLab instance in
the future, but I don't have time to do it anytime soon.
BTW, is there any proprietary JavaScript free alternative to
GitLab/GitHub? I would be very grateful for any recommendations.
(I noticed that my previous message was sent to the duplicate list.
Apologies for that).
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: how to get multi-line author in ODT export?
@ 2021-08-26 16:54 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-26 16:54 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Hi again,
Another simpler approach, with a filter:
#+TITLE: The kessel run in 12 parsecs
#+AUTHOR: Han Solo !!! Chewbacca !!! Lando Calrissian
#+BIND: org-export-filter-plain-text-functions (author-lb-filter)
#+begin_src emacs-lisp :exports results :results none
(defun author-lb-filter (text backend info)
(cond ((org-export-derived-backend-p backend 'odt)
(replace-regexp-in-string "!!!" "\n" text))
((org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string "!!!" "\\\\\\\\" text))))
#+end_src
Content...
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Hi Eric,
>
> I think the problem is in this two lines of `org-odt-template', that
> creates the meta.xml file inside the odt file:
>
> (format "<dc:creator>%s</dc:creator>\n" author)
> (format "<meta:initial-creator>%s</meta:initial-creator>\n" author)
>
> Perhaps, modifying them like this:
>
> (format "<dc:creator><![CDATA[%s]]></dc:creator>\n" (replace-regexp-in-string "\\\\\\\\" "\n" author))
> (format "<meta:initial-creator><![CDATA[%s]]></meta:initial-creator>\n" (replace-regexp-in-string "\\\\\\\\" "\n" author))
>
> We could do this in our documents:
>
> #+AUTHOR: Han Solo \\ Chewbacca
>
> (little tested)
>
> Best regards,
>
> Juan Manuel
>
> Eric S Fraga writes:
>
>> So, as usual, I answer my own question, sort of.
>>
>> The problem is that org exports the author text enclosed within a
>> special directives, specifically:
>>
>> (format "<text:initial-creator>%s</text:initial-creator>" author))
>>
>> New line directives are not allowed within this declaration, it
>> seems. Removing (manually) the initial-creator directive then works.
>>
>> So, my question would be: is this text:initial-creator tagging
>> necessary? If not, can we remove it? The OpenDocument schema is vague
>> about whether this is necessary. If we cannot remove it, i.e if
>> initial-creator is required in the document, could it be put in
>> separately (as a meta:initial-creator tag) so that the author field can
>> be more general?
>>
>> I am *not* an ODT expert of any sort. But it is my route to Word
>> documents when the need arises (which is luckily seldom).
>>
>> Anyway, no panic: I can simply manually edit the odt file just before
>> the final processing...
>>
>> Thank you,
>> eric
>
>
^ permalink raw reply [relevance 13%]
* Re: Retaking AUTO for \usepackage{fontenc}
@ 2024-02-14 22:03 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-14 22:03 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>>> neither do I, This is why I'm asking for people to tell me what they
>>> use ;-)
>>
>> The babel ini files (why hadn't I thought of this before :-): look in the babel ini files:
>
> May it be that babel automatically loads fontenc with appropriate parameters?
AFAIK, I'm afraid it's not possible. What is possible is to be able to
select a language in the middle of the document, without declaring it
before. But you need to load fontenc and the appropriate fontencodings.
According to the babel manual (p. 8), this functionality is only limited
to Latin, Cyrillic, Greek, Arabic, Hebrew, Cherokee, Armenian, and
Georgian.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: Experimental public branch for inline special blocks
@ 2024-03-02 10:57 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-02 10:57 UTC (permalink / raw)
To: emacs-orgmode
Hi, Stefan,
Stefan Nobis writes:
> first of all: Thank you for your great work. Looks really good.
You're welcome! :-)
> Just out of curiosity: Why a special syntax for alias expansion?
>
> From a syntax and user point of view, I think I would prefer a simpler
> syntax. So
>
> &alias{text}
>
> would check if an alias is registered and if yes use it. This way it
> would be easier to change/add options later on without the need for
> changing all the inline-block commands and add a "!" (not a big deal,
> just two rather simple replace commands).
I think you're right. I have removed the need for "!" in the last
commit.
Now the syntax is:
&alias{text}
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: [ANN] Please share useful blog posts on this list with the [BLOG] subject prefix
@ 2024-02-26 10:32 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-26 10:32 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode
Bastien writes:
> Adding [BLOG] or [TIP] in the subject prefix allows for such messages
> to be referenced on https://tracker.orgmode.org/news (along with [ANN]
> messages).
>
> It will then be possible to include these posts in the orgmode.org
> homepage, using e.g. https://tracker.orgmode.org/news.rss.
>
> This is experimental, let's see if this helps spread the word about
> useful blogs.
Great! Just one question: can articles be shared in languages other than
English? In that case, would it be necessary to add some more
prefixes, such as "Spanish", "French", "Italian", "Greek", etc.?
(If I shared something in Spanish, I could translate the article in the
body of the message).
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: set italian language in LaTeX export
@ 2024-02-19 15:11 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-19 15:11 UTC (permalink / raw)
To: Luca Ferrari; +Cc: emacs-org list
Luca Ferrari writes:
>> #+language:it
>> #+LaTeX_Header: \usepackage[AUTO]{babel}
>>
>
> Thanks, this solved the problem. Out of curiosity, why is not org-mode
> adding it automatically whenever a #+language setting is present?
> I'm just curious because it seems that, as an example, open-office
> exporting understands the language.
Hi, Luca. You may be interested in taking a look at this thread, where
this problem and other related issues such as fallback fonts in LaTeX
export are discussed:
https://list.orgmode.org/?t=20230830082719
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: set italian language in LaTeX export
@ 2024-02-19 11:11 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-19 11:11 UTC (permalink / raw)
To: Luca Ferrari; +Cc: emacs-org list
Luca Ferrari writes:
> #+language: it
>
> and I correctly got in the LaTeX buffer something like:
>
> pdflang={Italian}}
>
> but not something like:
>
> \usepackage[italian]{babel}
You must load the babel package with the AUTO option:
#+language:it
#+LaTeX_Header: \usepackage[AUTO]{babel}
(see 'LaTeX header and sectioning structure' in the Org Manual)
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: Link type for pdf-tools annotations
@ 2024-02-09 12:48 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-09 12:48 UTC (permalink / raw)
To: Irfan S; +Cc: orgmode
Irfan S writes:
> FYI, there is also
> [[https://github.com/fuxialexander/org-pdftools][org-pdftools]] which
> provides similar (and additional) functionality, and is on MELPA.
> Thanks for sharing your code.
Thank you very much, I didn't know that.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)
@ 2024-02-02 18:10 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-02 18:10 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> #+AUTHOR: author1
> #+FN_AUTHOR: footnote for author 1
>
> #+AUTHOR: author2
> #+FN_AUTHOR: footnote for author 2
Sorry if this is off topic, but something like this:
#+AUTHOR: Fred Astaire
#+AUTHOR: Ginger Rogers
is exported to LaTeX as:
\author{Fred Astaire Ginger Rogers}
Shouldn't there be some separation? In LaTeX the usual thing is:
\author{Fred Astaire \and Ginger Rogers}
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
@ 2023-09-21 18:28 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-21 18:28 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> With above code for LuaLaTeX, I have also appended:
>
> #+LATEX_COMPILER: lualatex
>
> even after specifying the LaTeX compiler to lualatex a report that
> says, the compiler seems to use pdflatex:
>
> ! Fatal Package fontspec Error: The fontspec package requires
> either XeTeX or
> (fontspec) LuaTeX.
> (fontspec)
> (fontspec) You must change your typesetting
> engine to,
> (fontspec) e.g., "xelatex" or "lualatex"
> instead of
> (fontspec) "latex" or "pdflatex".
>
> Type <return> to continue.
> ...
>
> l.45 \msg_fatal:nn {fontspec} {cannot-use-pdftex}
>
>
> Entire texlive packages are installed and lualatex binary is at:
>
> $ which lualatex
> /opt/texlive/2023/bin/x86_64-linux/lualatex
Can you please show here the value of 'org-latex-pdf-process'?
(M-x describe-variable RET org-latex-pdf-process RET)
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: Extract toc from org file
@ 2022-09-26 15:39 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-26 15:39 UTC (permalink / raw)
To: reza; +Cc: orgmode
reza writes:
> Is there a way to extract a toc from an org file e.g:
>
> #+INCLUDE: myfile.org :toc only
>
> I want to assemble the toc's from several files into one file and there
> seems to be no easy way to do this.
Maybe the org-make-toc package can help you with what you're looking for:
https://github.com/alphapapa/org-make-toc
You can choose a heading on every document to contain a TOC. And then link each heading via org-transclusion:
https://github.com/nobiot/org-transclusion
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
@ 2022-09-26 7:47 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-26 7:47 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> What I have in mind is to modify `org-export-read-attribute' directly.
> Then, we can call `org-export-read-attribute' in `org-export-data';
> resolve the refs in the template (re-use code from
> `org-babel-ref-resolve' and `org-babel-parse-multiple-vars'); do normal
> export and pass it to the template. Before running the normal export, we
> strip :export_template from the INFO to avoid issues with ox-html which
> puts every single attr into the generated html.
OK, it makes sense. I can try something on this idea, although I'm
afraid not in the short term. If someone else wants to do it I have no
problem.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: error org export to pdf when latex letter class has been added to org-latex-classes
@ 2022-09-13 17:55 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-13 17:55 UTC (permalink / raw)
To: M. Pger; +Cc: orgmode
Hi,
M. Pger writes:
> (/usr/share/texlive/texmf-dist/tex/latex/natbib/natbib.sty
>
> ! LaTeX Error: Environment thebibliography undefined.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type H <return> for immediate help.
> ...
>
> l.1063 \renewenvironment{thebibliography}
> [1]{%
> ?
> ! Emergency stop.
> ...
>
> l.1063 \renewenvironment{thebibliography}
> [1]{%
> ! ==> Fatal error occurred, no output PDF file produced!
Are you including citations in your letter? Maybe this is related:
https://latex.org/forum/viewtopic.php?f=4&t=3359
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: Agenda 'Org view' (org-projection?)
@ 2022-09-06 14:21 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-06 14:21 UTC (permalink / raw)
To: Eduardo Suarez; +Cc: orgmode
Hi, Eduardo:
Eduardo Suarez writes:
> Based on my previous mail "Manual Ordering and Dynamic Priority" I would like
> also to comment about this related idea.
>
> In Agenda, it is possible to generate different views. I wonder whether it
> would be possible to generate an "org mode" view. That is, a buffer in org-mode
> format with all the tasks from our agenda query (no really a sparse tree view).
> Then that file could be edited and reordered to create a planning. If the file
> could also sync with new queries that would be great. I think of that maybe as
> a package called 'org-projection' (project org into org).
>
> With such feature, I could have a general org file e.g. for a working project,
> and then a planning (projected) file in association with it. I would add the
> latter to the Agenda files.
>
> I can't do lisp development and have no idea if that makes sense, but I just
> wanted to share this idea with you.
I think this is not 100% related to what you're proposing, but if it
helps, I use the excellent org-super-agenda package a lot, which allows
you to sort and compose the agenda view according to many parameters:
tags, priorities, properties, etc:
https://github.com/alphapapa/org-super-agenda
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: Have all the tags of a heading, with a tag hierarchy
@ 2022-08-28 16:21 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-28 16:21 UTC (permalink / raw)
To: Cletip Cletip; +Cc: orgmode
Cletip Cletip writes:
> After multiple searches on the internet, I did not find the answer to
> my question (which is the subject of this mail): when calling the
> "org-get-tags" function, only the tags put on the heading, and not the
> inherited tags, are retrieved. How can I get the inherited tags as
> well? Does such a function already exist? Did I miss an essential
> variable?
In my case, I do manage to get the iherited tags. Do you have
`org-use-tag-inheritance' set to non-nil?
According to the `org-get-tags' docstring:
> According to ‘org-use-tag-inheritance’, tags may be inherited from
> parent headlines, and from the whole document, through
> ‘org-file-tags’. In this case, the returned list of tags contains tags
> in this order: file tags, tags inherited from parent headlines, local
> tags. If a tag appears multiple times, only the most local tag is
> returned.
and
> However, when optional argument LOCAL is non-nil, only return tags
> specified at the headline.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved
@ 2022-08-06 21:32 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-06 21:32 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> FYI, there is display-fill-column-indicator-mode, which is useful to
> guide the docstring in Elisp. Just need to set fill-column to 80.
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e47bcb02133608e37bc4c532aec4d4723f8eeca8
Thanks a lot for the suggestion, Ihor. With this I also realize that 90%
of my functions have the first line of the docstring too long...
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-18 11:01 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-18 11:01 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Juan Manuel Macías writes:
> latex-lang: babel(sorbian) variant(upper) provide(hebrew:import,hyphenrules=+) options(bidi=default), others(french,catalan)
>
> returns:
>
> \usepackage[french,catalan,uppersorbian,bidi=default]{babel}
> \babelprovide[import,hyphenrules=+]{hebrew}
PS: In fact, I think that this new implementation would no longer depend
on a list of languages neither for babel nor for polyglossia, since it
is not connected to the #+language keyword. The old list would be kept
for backwards compatibility.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 13%]
* Re: [External] : Re: missing a character / font in agenda?
@ 2022-07-12 20:03 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-12 20:03 UTC (permalink / raw)
To: Daniel Ortmann; +Cc: orgmode
Juan Manuel Macías writes:
> The most reasonable thing would be to use a more
> common symbol. But I'm still intrigued by the origin of that symbol...
It seems that the culprit is in line 1592 of org-agenda.el
I think this should be considered a bug, since the glyph used (LEFTWARDS
TRIANGLE-HEADED ARROW / #2b60) is not present in most fonts.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 13%]
* Re: Raw Org AST snippets for "impossible" markup
@ 2021-12-06 16:56 13% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-06 16:56 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Juan Manuel Macías writes:
> I would suggest, however, not to use the term 'italics [...blah blah...]'
Sorry for the noise! I think I messed myself up...
Naturally, 'italic' (or 'bold') is required: (italic () \"inter\")
Best regards,
Juan Manuel
^ permalink raw reply [relevance 13%]
* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
@ 2021-10-28 19:39 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-28 19:39 UTC (permalink / raw)
To: Vikas Rawal; +Cc: orgmode
Juan Manuel Macías writes:
> \begin{longtblr}[options 1 options 2 options 3 options 4]{align}
PS: I think the options should be separated by commas. In this
case, it's necessary to replace the line:
(mapconcat (lambda (x) (mapconcat 'identity x "")) options-list " ")))
by this line:
(mapconcat (lambda (x) (mapconcat 'identity x "")) options-list ",")))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 13%]
* Re: Unable to configure emacs 27.2 to use org 9.5
@ 2021-10-18 22:28 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-18 22:28 UTC (permalink / raw)
To: Detlef Steuer; +Cc: orgmode
Hi Detlef,
Detlef Steuer writes:
> I have installed 9.5 with package-install in a clean emacs session,
> it is shown as installed, too, but whatever I try, my org-version is
> shown as 9.4.6, which is included in 27.2.
> (I assume, and therefore citeproc unavailable)
Have you looked in your elpa directory if you see this path: .../elpa/org-9.5/?
Have you tried uninstalling Org and reinstalling it?
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 13%]
* Re: org-attach a directory?
@ 2021-06-10 16:13 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-10 16:13 UTC (permalink / raw)
To: orgmode
You could also modify some line in org-attach-attach, for example:
...
((eq method 'cp) (if (file-directory-p file)
(copy-directory file attach-file)
(copy-file file attach-file)))
...
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> If I have to stay with a workaround that covers many scenarios, I would
> stay with Ihor's snippet, which seems to me simpler than the patch that
> I suggested before, and you don't need to define new attach
> commands/methods. I would vote for a patch in that direction (Ihor's
> code).
^ permalink raw reply [relevance 13%]
* Re: [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part
2021-06-04 11:31 13% ` Juan Manuel Macías
@ 2021-06-06 22:34 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-06 22:34 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> To simplify what I mentioned in my previous message, the bug is simply
> reproducible with any link, when running `org-toggle-link-display'.
>
> I'm not sure, but I would say it was introduced in the commit:
>
> 8bdcf51ac lisp/org.el: Update previews correctly when color chnages
I correct myself. I think the commit where this problem was introduced is:
979e82fc3 Make sure that headline faces take precedence
Best regards,
Juan Manuel
^ permalink raw reply [relevance 13%]
* Re: [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part
2021-06-03 21:11 10% [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part Juan Manuel Macías
@ 2021-06-04 11:31 13% ` Juan Manuel Macías
2021-06-06 22:34 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-04 11:31 UTC (permalink / raw)
To: orgmode
Hello again,
To simplify what I mentioned in my previous message, the bug is simply
reproducible with any link, when running `org-toggle-link-display'.
I'm not sure, but I would say it was introduced in the commit:
8bdcf51ac lisp/org.el: Update previews correctly when color chnages
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Hi all,
>
> In master:
>
> if I do:
>
> (org-link-set-parameters "foo"
> :display 'full
> :face '(:foreground "chocolate" :weight bold :underline t))
>
> and then:
>
> [[foo:target][description]]
>
> the face parameter is only applied in the description part.
>
> Expected result: shouldn't the face be applied to the entire link?
>
> Best regards,
>
> Juan Manuel
>
^ permalink raw reply [relevance 13%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-13 16:48 12% ` Juan Manuel Macías
@ 2024-03-13 17:16 14% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-13 17:16 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Juan Manuel Macías writes:
> It was necessary with the previous implementation, which excessively
> abused regexp. Not now (I want to do a few more tests and I'll make a
> new commit with the changes). With the new implementation, now:
>
> - do not export
>
> * export only the content
>
> = rest (full)
>
> =* rest (contents only)
>
> backend- do not export this backend (and the backends derived from it)
>
> backend+ (or, perhaps, just "backend") export this backend (idem)
>
> backend* export this backend (contents only) (idem)
>
> I think your example with the video link would also be possible with the
> new implementation.
Please try the latest commit:
@@[:export html-]{Watch [[https://youtube.com/...][Org mode in action demo]] video.}
#+begin_export html
<iframe src="https://youtube.com/embed/..."
title="Org mode in action demo"
width="..." height="..."></iframe>
#+end_export
It would not be exported to html or its derived backends.
(In your example you used `-html' instead of `html-'. I have no
preference for one variant or another).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 14%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-09 11:48 12% ` Juan Manuel Macías
@ 2024-03-09 15:24 14% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-09 15:24 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Juan Manuel Macías writes:
> Max Nikulin writes:
>
>> However it is still gives
>>
>> (org-export-string-as "Alpha@Beta["
>> 'html
>> '(:export-options (body-only)))
>> Debugger entered--Lisp error: (wrong-type-argument
>> number-or-marker-p nil)
>
> I think the problem is the contents-begin variable. When it is nil it
> produces that error. I will make a new commit to fix the bug.
>
> Thanks for all the tests you're doing!
Well, I hope that in the last commit the two bugs that you mentioned
have been fixed. Please check:
Albha@Beta[
@sp@n{lorem ipsum}
@@@@{lorem ipsum}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 14%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-08 18:44 12% ` Juan Manuel Macías
@ 2024-03-08 18:57 14% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-08 18:57 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> escribió:
> Ok, I think you and Maxim are right. This is a clear bug. I hope it
> was fixed in the last commit.
Now:
(org-export-string-as "Alpha@Beta{" 'latex t))
==> Alpha@Beta\{
(org-export-string-as "Alpha@Beta{gamma}" 'latex t))
==> Alpha\Beta{gamma}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 14%]
Results 1-200 of ~700 next [<= 10%] | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2021-10-20 14:57 13% Fancy underlines in Org to LaTeX Juan Manuel Macías
[not found] <E1ocmvz-0002iB-2M@fencepost.gnu.org>
2022-09-30 3:31 ` [HELP] Fwd: Org format as a new standard source format for GNU manuals Ihor Radchenko
2022-09-30 12:49 ` Max Nikulin
2022-10-01 3:30 ` Ihor Radchenko
2022-10-01 10:42 ` Max Nikulin
2022-10-01 11:01 ` Ihor Radchenko
2022-10-01 11:27 ` Max Nikulin
2022-10-02 4:59 ` Ihor Radchenko
2022-10-02 10:38 ` Fraga, Eric
2022-10-02 13:02 ` Ihor Radchenko
2022-10-02 13:47 13% ` Juan Manuel Macías
[not found] <100cb12a-b3f1-739a-84f1-847f5e86a8bc@housseini.me>
2022-09-26 11:53 ` Extract toc from org file reza
2022-09-26 15:39 13% ` Juan Manuel Macías
2021-11-21 15:36 13% org-critical-edition (new version) Juan Manuel Macías
2022-08-07 12:53 13% org-verse-num: display verse numbers within a verse block Juan Manuel Macías
2022-08-07 13:39 ` Colin Baxter
2022-08-07 14:22 13% ` Juan Manuel Macías
2022-10-15 15:14 12% Doubts about a function for my org-capture template Juan Manuel Macías
2021-12-08 20:03 12% Making a dictionary in Org Juan Manuel Macías
2021-10-02 10:48 12% [Question] A single *-language-alist in ox-latex.el? Juan Manuel Macías
2021-10-02 11:08 ` Stefan Nobis
2021-10-02 19:20 12% ` Juan Manuel Macías
2023-08-04 7:25 12% [patch] Fix inner smart quotes in French Juan Manuel Macías
2023-08-05 7:08 ` Ihor Radchenko
2023-08-05 10:51 12% ` Juan Manuel Macías
2024-02-12 15:24 11% [patch] ox.latex.el: Add missing character warnings Juan Manuel Macías
2024-02-12 18:15 12% ` Juan Manuel Macías
2024-02-12 18:26 ` Ihor Radchenko
2024-02-12 19:17 ` Juan Manuel Macías
2024-02-12 19:52 ` Ihor Radchenko
2024-02-12 21:20 ` Juan Manuel Macías
2024-02-13 14:29 ` Ihor Radchenko
2024-02-13 16:01 11% ` Juan Manuel Macías
2022-10-15 21:35 11% [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX Juan Manuel Macías
2022-10-16 15:04 ` Max Nikulin
2022-10-16 17:14 ` Line breaks and brackets in LaTeX export (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
2022-10-17 9:04 ` Ihor Radchenko
2022-10-17 11:30 ` Line breaks and brackets in LaTeX export Juan Manuel Macías
2022-10-17 15:01 11% ` Juan Manuel Macías
2022-10-17 16:46 ` Max Nikulin
2022-10-17 18:04 ` Juan Manuel Macías
2022-10-18 4:41 ` Ihor Radchenko
2022-10-18 14:23 ` Juan Manuel Macías
2022-10-19 3:57 ` Ihor Radchenko
2022-10-19 5:11 ` Max Nikulin
2022-10-19 11:16 ` Juan Manuel Macías
2022-10-19 12:30 12% ` Juan Manuel Macías
2024-01-02 23:46 11% [possible patch] Remove the '\\[0pt]' string from the last line of a verse block " Juan Manuel Macías
2023-10-06 8:07 11% [proof of concept, tip] 'Templates with arguments' using org src blocks Juan Manuel Macías
2024-02-25 13:53 11% A question about local/experimental branches Juan Manuel Macías
2024-02-25 14:05 ` Ihor Radchenko
2024-02-25 15:10 12% ` Juan Manuel Macías
2024-03-22 1:04 11% [bug] Smart quotes: confusion of apostrophe with second level quotes Juan Manuel Macías
2024-02-08 22:13 11% Link type for pdf-tools annotations Juan Manuel Macías
2024-02-08 23:25 ` Ihor Radchenko
2024-02-09 0:40 11% ` Juan Manuel Macías
2024-02-09 12:13 ` Irfan S
2024-02-09 12:48 13% ` Juan Manuel Macías
2023-08-18 18:27 10% [Tip] Popup-menu with several actions for a link Juan Manuel Macías
2023-08-19 19:53 ` Ihor Radchenko
2023-08-19 20:29 11% ` Juan Manuel Macías
2021-04-12 13:50 10% [Patch] to correctly sort the items with emphasis marks in a list Juan Manuel Macías
2021-03-31 18:56 10% About exporting Juan Manuel Macías
2021-06-03 21:11 10% [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part Juan Manuel Macías
2021-06-04 11:31 13% ` Juan Manuel Macías
2021-06-06 22:34 13% ` Juan Manuel Macías
2023-08-30 8:25 10% Fallback fonts in LaTeX export for non latin scripts Juan Manuel Macías
2023-08-31 8:17 ` Ihor Radchenko
2023-08-31 11:42 ` Juan Manuel Macías
2023-09-01 9:18 ` Ihor Radchenko
2023-09-02 21:39 ` Juan Manuel Macías
2023-09-03 7:22 ` Ihor Radchenko
2023-09-03 11:05 ` Juan Manuel Macías
2023-09-04 8:09 ` Ihor Radchenko
2023-09-04 22:22 ` Juan Manuel Macías
2023-09-05 16:42 ` Max Nikulin
2023-09-05 18:33 12% ` Juan Manuel Macías
2023-09-05 10:44 ` Ihor Radchenko
2023-09-20 14:03 ` Juan Manuel Macías
2023-09-21 9:00 ` Ihor Radchenko
2023-09-24 18:24 12% ` Juan Manuel Macías
2021-10-22 15:01 10% [tip] Export some footnotes as pdf annotations (LaTeX) or comments (odt) Juan Manuel Macías
2021-06-07 13:09 10% org-critical-edition (a package for philologists and classicists) Juan Manuel Macías
2021-03-22 21:59 10% Items with emphasis marks are not sorted properly in a list Juan Manuel Macías
2021-03-23 8:36 13% ` Juan Manuel Macías
[not found] <mailman.57.1618243212.17744.emacs-orgmode@gnu.org>
2021-04-12 18:51 ` [Patch] to correctly sort the items with emphasis marks " Ypo
2021-04-12 23:18 10% ` Juan Manuel Macías
2021-04-05 9:25 [tip] search this mailing list with helm-surfraw Juan Manuel Macías
2021-04-25 5:00 ` Bastien
2021-04-27 20:20 10% ` Juan Manuel Macías
2024-03-11 9:56 Footnotes on line and not raised Colin Baxter
2024-03-11 10:12 ` Colin Baxter
2024-03-11 11:03 12% ` Juan Manuel Macías
2024-02-19 10:08 set italian language in LaTeX export Luca Ferrari
2024-02-19 11:11 13% ` Juan Manuel Macías
2024-02-19 14:06 ` Luca Ferrari
2024-02-19 15:11 13% ` Juan Manuel Macías
2021-06-23 19:27 appearance of list as results from evaluating code blocks Johannes Brauer
2021-06-23 19:43 10% ` Juan Manuel Macías
2021-06-01 15:36 suggestion to change default org-latex-pdf-process to latexmk Bruce D'Arcus
2021-06-01 15:52 10% ` Juan Manuel Macías
2021-06-02 0:00 ` Tim Cross
2021-06-02 6:07 ` Stefan Nobis
2021-06-02 8:40 10% ` Juan Manuel Macías
2021-06-06 18:19 [PATCH] Allow LaTeX reference command (\ref) to be customised Timothy
2021-06-06 18:29 10% ` Juan Manuel Macías
2021-01-19 22:05 Region-based meta-notes Lawrence Bottorff
2021-01-19 22:39 10% ` Juan Manuel Macías
2020-12-01 12:08 Footnote definition within a verse block has spurious line breaks when exported to LaTeX Juan Manuel Macías
2020-12-05 9:09 ` Nicolas Goaziou
2020-12-05 13:47 10% ` Juan Manuel Macías
2024-02-10 1:58 [patch] Add two new header args to LaTeX block Juan Manuel Macías
2024-02-10 14:37 ` Ihor Radchenko
2024-02-10 15:20 12% ` Juan Manuel Macías
2024-02-10 16:35 ` Ihor Radchenko
2024-02-10 17:48 12% ` Juan Manuel Macías
2024-02-10 19:35 10% ` Juan Manuel Macías
2024-02-10 21:07 ` Ihor Radchenko
2024-02-10 23:34 10% ` Juan Manuel Macías
2024-02-11 14:43 ` Ihor Radchenko
2024-02-11 20:01 ` Juan Manuel Macías
2024-02-13 13:42 ` Ihor Radchenko
2024-02-13 20:25 11% ` Juan Manuel Macías
2024-02-18 14:20 ` Ihor Radchenko
2024-02-18 13:43 10% ` Juan Manuel Macías
2024-02-19 11:15 ` Ihor Radchenko
2024-02-19 13:24 12% ` Juan Manuel Macías
2022-07-12 17:18 missing a character / font in agenda? Daniel Ortmann
2022-07-12 17:58 ` Juan Manuel Macías
2022-07-12 18:45 ` [External] : " Daniel Ortmann
2022-07-12 19:52 ` Juan Manuel Macías
2022-07-12 20:03 13% ` Juan Manuel Macías
2022-07-08 12:17 LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX? Juan Manuel Macías
2022-07-08 18:49 ` Thomas S. Dye
2022-07-09 2:23 ` Max Nikulin
2022-07-09 10:42 ` Juan Manuel Macías
2022-07-09 12:15 ` Max Nikulin
2022-07-09 14:58 ` Juan Manuel Macías
[not found] ` <b58ee3cc-c58c-b627-9cc5-51993020db2c@gmail.com>
2022-07-09 20:22 ` Juan Manuel Macías
2022-07-10 20:23 ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Juan Manuel Macías
2022-07-10 20:31 12% ` Juan Manuel Macías
2022-07-11 8:05 ` Stefan Nobis
2022-07-11 11:39 ` Juan Manuel Macías
2022-07-11 12:04 12% ` Juan Manuel Macías
2022-10-06 13:20 Interest in an Org video meetup? Russell Adams
2022-10-06 20:09 ` Juan Manuel Macías
2022-10-07 1:43 ` Ihor Radchenko
2022-10-07 1:47 ` Russell Adams
2022-10-07 10:37 13% ` Juan Manuel Macías
2021-05-28 2:54 Smart quotes not working correctly with single quotes Andreas Gösele
2021-05-28 10:10 ` Juan Manuel Macías
2021-05-28 15:42 ` Andreas Gösele
2021-05-28 17:02 ` Juan Manuel Macías
2021-05-28 20:27 ` Andreas Gösele
2021-05-28 20:37 10% ` Juan Manuel Macías
2022-09-13 15:54 error org export to pdf when latex letter class has been added to org-latex-classes M. Pger
2022-09-13 17:55 13% ` Juan Manuel Macías
2023-03-21 3:36 org-ctags land grab Nick Dokos
2023-08-11 9:44 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? Ihor Radchenko
2023-08-12 12:46 ` Bastien Guerry
2023-08-12 22:18 ` Samuel Wales
2023-08-14 13:19 ` Fraga, Eric
2023-08-22 15:15 ` Bastien Guerry
2023-08-23 9:33 ` Ihor Radchenko
2023-08-24 11:39 ` Bastien Guerry
2023-08-24 11:44 ` Ihor Radchenko
2023-08-24 12:08 ` Bastien Guerry
2023-08-24 12:15 ` Ihor Radchenko
2023-08-24 12:36 ` Bastien Guerry
2023-08-24 12:40 ` Ihor Radchenko
2023-08-24 12:48 ` Bastien Guerry
2023-08-24 12:56 ` Ihor Radchenko
2023-08-24 13:02 ` Bastien Guerry
2023-08-24 13:36 ` Ihor Radchenko
2023-08-24 14:08 ` Bastien Guerry
2023-08-25 9:44 ` [DISCUSSION] Re-design of inlinetasks (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?) Ihor Radchenko
2023-08-25 17:58 ` [DISCUSSION] Re-design of inlinetasks Juan Manuel Macías
2023-08-26 10:58 ` Ihor Radchenko
2023-08-26 11:42 10% ` Juan Manuel Macías
2023-08-26 12:33 ` Ihor Radchenko
2023-08-26 14:21 ` Juan Manuel Macías
2023-08-26 16:33 ` Ihor Radchenko
2023-08-26 17:31 11% ` Juan Manuel Macías
2022-07-31 1:00 [PATCH] ox-latex.el: `org-latex-language-alist' improved Juan Manuel Macías
2022-08-03 11:23 ` Ihor Radchenko
2022-08-04 10:04 ` Juan Manuel Macías
2022-08-06 7:13 ` Ihor Radchenko
2022-08-06 21:32 13% ` Juan Manuel Macías
2021-04-03 9:31 First steps exporting to tex Ypo
2021-04-03 10:15 ` Martin Steffen
2021-04-04 11:04 ` Ypo
2021-04-04 11:36 10% ` Juan Manuel Macías
2020-12-27 16:44 Bug: Tildes in URL impact visible link text [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)] Chris Hunt
2020-12-27 18:12 10% ` Juan Manuel Macías
2020-12-27 20:14 ` tomas
2020-12-27 21:33 10% ` Juan Manuel Macías
2021-10-26 16:05 [patch] ox-latex.el: add `:options' LaTeX attribute to tables Juan Manuel Macías
2021-10-27 3:44 ` Vikas Rawal
2021-10-27 15:52 ` Juan Manuel Macías
2021-10-28 16:10 ` Vikas Rawal
2021-10-28 18:02 ` Juan Manuel Macías
2021-10-28 19:39 13% ` Juan Manuel Macías
2021-02-15 17:37 'false' list item Juan Manuel Macías
2021-02-21 6:56 ` Kyle Meyer
2021-02-21 19:33 ` Juan Manuel Macías
2021-02-21 19:40 ` Diego Zamboni
2021-02-21 21:27 ` Samuel Wales
2021-02-21 22:25 10% ` Juan Manuel Macías
2021-02-21 7:05 ` Tim Cross
2021-02-21 14:49 10% ` Juan Manuel Macías
2021-08-26 13:43 how to get multi-line author in ODT export? Eric S Fraga
2021-08-26 14:24 ` Eric S Fraga
2021-08-26 16:05 ` Juan Manuel Macías
2021-08-26 16:54 13% ` Juan Manuel Macías
2024-03-01 20:34 Experimental public branch for inline special blocks Juan Manuel Macías
2024-03-06 16:53 ` To avoid zero width space: " Max Nikulin
2024-03-06 18:27 12% ` Juan Manuel Macías
2024-03-06 21:13 12% ` Juan Manuel Macías
2024-03-03 20:29 ` Juan Manuel Macías
2024-03-10 2:08 ` `:export' attribute?: " Juan Manuel Macías
2024-03-10 13:54 13% ` Juan Manuel Macías
2024-03-11 10:27 ` Max Nikulin
2024-03-11 13:59 11% ` Juan Manuel Macías
2024-03-11 17:01 ` Max Nikulin
2024-03-11 20:19 11% ` Juan Manuel Macías
2024-03-12 8:32 ` Stefan Nobis
2024-03-12 13:45 11% ` Juan Manuel Macías
2024-03-12 16:20 ` Max Nikulin
2024-03-12 17:41 12% ` Juan Manuel Macías
2024-03-13 16:08 ` Max Nikulin
2024-03-13 16:48 12% ` Juan Manuel Macías
2024-03-13 17:16 14% ` Juan Manuel Macías
2024-03-15 2:19 ` Juan Manuel Macías
2024-03-15 10:52 ` Max Nikulin
2024-03-15 16:26 12% ` Juan Manuel Macías
2024-03-04 17:13 ` naming: " Max Nikulin
2024-03-04 17:29 ` Ihor Radchenko
2024-03-04 17:49 12% ` Juan Manuel Macías
2024-03-05 10:53 ` Max Nikulin
2024-03-05 15:16 11% ` Juan Manuel Macías
2024-03-02 8:29 ` Stefan Nobis
2024-03-02 10:57 13% ` Juan Manuel Macías
2024-03-05 16:47 ` smallcaps: " Max Nikulin
2024-03-05 17:28 10% ` Juan Manuel Macías
2024-03-06 10:55 ` Max Nikulin
2024-03-06 15:21 11% ` Juan Manuel Macías
2024-03-07 10:57 ` false positives: " Max Nikulin
2024-03-07 11:06 12% ` Juan Manuel Macías
2024-03-07 11:18 ` Ihor Radchenko
2024-03-07 15:53 12% ` Juan Manuel Macías
2024-03-07 16:09 ` Ihor Radchenko
2024-03-07 16:57 12% ` Juan Manuel Macías
2024-03-07 18:21 12% ` Juan Manuel Macías
2024-03-08 13:58 ` Max Nikulin
2024-03-08 15:44 12% ` Juan Manuel Macías
2024-03-08 16:15 ` Ihor Radchenko
2024-03-08 18:44 12% ` Juan Manuel Macías
2024-03-08 18:57 14% ` Juan Manuel Macías
2024-03-09 11:10 ` Max Nikulin
2024-03-09 11:48 12% ` Juan Manuel Macías
2024-03-09 15:24 14% ` Juan Manuel Macías
2021-05-30 17:33 TMIO Pre-release, request for feedback Timothy
2021-05-30 19:42 10% ` Juan Manuel Macías
2022-02-17 14:56 Question Regarding Creating HTML Style Buttons With Org Mode Samuel Banya
2022-02-17 22:10 ` Juan Manuel Macías
2022-02-18 19:59 ` Samuel Banya
2022-02-18 20:38 ` Juan Manuel Macías
2022-02-18 20:51 12% ` Juan Manuel Macías
2022-02-19 1:02 ` Samuel Banya
2022-02-19 9:41 ` Juan Manuel Macías
2022-02-19 9:51 12% ` Juan Manuel Macías
2021-04-02 15:54 Including Email Address in the Reply in Mailing-list Husain Alshehhi
2021-04-02 23:08 ` Tim Cross
2021-04-02 23:45 10% ` Juan Manuel Macías
2022-09-27 1:48 org exported pdf files Jude DaShiell
2022-09-27 2:48 ` Ihor Radchenko
2022-09-27 3:15 ` Jude DaShiell
2022-09-27 3:24 ` Ihor Radchenko
2022-09-27 4:31 ` Jude DaShiell
2022-09-27 4:58 ` Ihor Radchenko
2022-09-28 4:36 ` Jude DaShiell
2022-09-28 4:53 ` Timothy
2022-09-28 6:48 ` Jude DaShiell
2022-09-28 8:47 ` Tim Cross
2022-09-28 9:19 ` Timothy
2022-09-28 17:08 ` Tim Cross
2022-09-28 18:23 12% ` Juan Manuel Macías
2021-05-17 15:41 Multilingual support (proposals and state of the question) Juan Manuel Macías
2021-05-17 16:03 ` Denis Maier
2021-05-17 18:10 10% ` Juan Manuel Macías
2022-08-28 15:37 Have all the tags of a heading, with a tag hierarchy Cletip Cletip
2022-08-28 16:21 13% ` Juan Manuel Macías
2024-02-01 7:07 RFI: LaTeX - AUTO for \usepackage{inputenc} Pedro Andres Aranda Gutierrez
2024-02-02 16:00 ` [RFC] LaTeX - automatically configure encoding when exporting non-Latin languages Ihor Radchenko
2024-02-02 16:18 12% ` Juan Manuel Macías
2023-10-01 15:08 Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX? Juan Manuel Macías
2023-10-01 18:07 12% ` Juan Manuel Macías
2023-10-02 13:10 ` Ihor Radchenko
2023-10-02 14:55 ` Juan Manuel Macías
2023-10-04 9:12 ` Ihor Radchenko
2023-10-04 14:34 11% ` Juan Manuel Macías
2024-02-12 6:36 Retaking AUTO for \usepackage{fontenc} Pedro Andres Aranda Gutierrez
2024-02-12 14:01 ` Ihor Radchenko
2024-02-13 7:51 ` Pedro Andres Aranda Gutierrez
2024-02-13 11:57 13% ` Juan Manuel Macías
2024-02-13 16:47 ` Pedro Andres Aranda Gutierrez
2024-02-13 17:22 11% ` Juan Manuel Macías
2024-02-14 14:55 ` Ihor Radchenko
2024-02-14 22:03 13% ` Juan Manuel Macías
2021-10-03 15:28 [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Juan Manuel Macías
2022-07-10 9:25 ` Ihor Radchenko
2022-07-14 12:34 ` Juan Manuel Macías
2022-07-17 9:55 ` Ihor Radchenko
2022-07-19 15:01 ` Juan Manuel Macías
2022-07-19 17:01 ` Max Nikulin
2022-07-19 19:31 ` Juan Manuel Macías
2022-07-20 16:12 ` Max Nikulin
2022-07-20 21:30 ` Juan Manuel Macías
2022-07-21 14:36 ` Max Nikulin
2022-07-21 15:39 ` Juan Manuel Macías
2022-07-22 12:16 ` Max Nikulin
2022-07-22 12:49 ` Juan Manuel Macías
2022-07-22 14:07 12% ` Juan Manuel Macías
2022-07-17 14:48 ` Juan Manuel Macías
2022-07-18 6:44 ` Ihor Radchenko
2022-07-18 10:32 ` Juan Manuel Macías
2022-07-18 11:01 13% ` Juan Manuel Macías
2022-07-14 15:12 ` Max Nikulin
2022-07-14 15:53 ` Juan Manuel Macías
2022-07-14 18:17 10% ` Juan Manuel Macías
2021-03-24 1:33 "Org" source blocks and minted Michael Gauland
2021-03-24 4:18 10% ` Juan Manuel Macías
2021-03-24 4:24 ` Timothy
2021-03-26 11:55 10% ` Juan Manuel Macías
2021-03-17 20:29 Syntax Proposal: Multi-line Table Cells/Text Wrapping Atlas Cove
2021-03-17 22:07 ` Juan Manuel Macías
2021-03-18 13:38 ` Atlas Cove
2021-03-18 15:15 10% ` Juan Manuel Macías
2021-03-18 14:26 ` Timothy
2021-03-18 14:31 ` Atlas Cove
2021-03-18 21:58 ` Tim Cross
2021-03-18 22:41 ` Juan Manuel Macías
2021-03-19 8:08 ` tomas
2021-03-19 8:44 10% ` Juan Manuel Macías
2021-03-19 8:53 ` tomas
2021-03-19 9:22 ` Juan Manuel Macías
2021-03-19 10:14 ` tomas
2021-03-19 10:53 ` Juan Manuel Macías
2021-03-19 11:08 12% ` Juan Manuel Macías
2020-12-27 13:02 A way to avoid unwanted new lines when using paragraph quotes? Kashyap Chamarthy
2020-12-27 13:55 10% ` Juan Manuel Macías
2021-04-05 20:48 Choosing a LaTeX Compiler (my predilection for LuaTeX) Juan Manuel Macías
2021-04-05 21:17 ` Dr. Arne Babenhauserheide
2021-04-05 21:36 ` Juan Manuel Macías
2021-04-06 19:03 ` physiculus
2021-04-06 19:13 ` Juan Manuel Macías
2021-04-07 16:57 ` physiculus
2021-04-07 17:26 ` Juan Manuel Macías
2021-04-07 17:53 ` physiculus
2021-04-07 19:52 10% ` Juan Manuel Macías
2021-04-06 19:46 ` tomas
2021-04-06 20:09 10% ` Juan Manuel Macías
2021-12-27 1:22 caption width in LateX export Seb
2021-12-27 7:41 ` Juan Manuel Macías
2021-12-27 9:09 12% ` Juan Manuel Macías
2021-02-28 20:21 printing org table landscape on complete page Andrés Ramírez
2021-02-28 20:53 10% ` Juan Manuel Macías
2021-02-16 16:30 [question] lisp code in :results header arg.? Juan Manuel Macías
2021-02-16 17:58 ` Berry, Charles via General discussions about Org-mode.
2021-02-16 18:25 10% ` 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 ` Juan Manuel Macías
2022-05-28 0:18 10% ` Juan Manuel Macías
2021-05-20 7:14 can't install footnotes in certain table cells Uwe Brauer
2021-05-20 9:57 ` [can't insert footnotes in all table cells] (was: can't install footnotes in certain table cells) Uwe Brauer
2021-05-20 10:06 ` [org-footnote--allow-reference-p] (was: [can't insert footnotes in all table cells]) Uwe Brauer
2021-05-20 10:17 10% ` [org-footnote--allow-reference-p] Juan Manuel Macías
2021-05-20 10:21 ` [org-footnote--allow-reference-p] Uwe Brauer
2021-05-20 10:38 10% ` [org-footnote--allow-reference-p] Juan Manuel Macías
2021-12-31 10:14 [BUG] Underlined text in parentheses is not exported correctly Juan Manuel Macías
2021-12-31 11:08 12% ` Juan Manuel Macías
2021-01-05 18:33 Inserting LaTex expressions using a filter fails Mart van de Wege
2021-01-05 21:58 10% ` Juan Manuel Macías
2021-01-06 7:50 ` Mart van de Wege
2021-01-06 11:51 10% ` Juan Manuel Macías
2021-01-06 12:00 ` Mart van de Wege
2021-01-06 12:24 10% ` Juan Manuel Macías
2021-01-06 15:17 ` Mart van de Wege
2021-01-06 15:58 10% ` Juan Manuel Macías
2021-04-04 10:31 how to export (latex) a image without using figure Uwe Brauer
2021-04-04 11:17 10% ` Juan Manuel Macías
2024-02-26 8:55 [ANN] Please share useful blog posts on this list with the [BLOG] subject prefix Bastien
2024-02-26 10:32 13% ` Juan Manuel Macías
2021-06-11 17:53 Failure to resolve internal links on ox-html export? Tim Visher
2021-06-11 18:31 10% ` Juan Manuel Macías
2022-10-23 15:16 [off-topic] E-readers and Org-Mode Juan Manuel Macías
2022-10-24 16:42 ` Jeffrey DeLeo
2022-10-24 17:16 ` Fraga, Eric
2022-10-24 18:34 ` Juan Manuel Macías
2022-10-29 9:03 12% ` Juan Manuel Macías
2021-07-05 19:44 convert subtree or nested list to table Matt Price
2021-07-05 20:01 10% ` Juan Manuel Macías
2024-02-20 20:35 [proof of concept] inline language blocks Juan Manuel Macías
2024-02-21 8:42 ` Ihor Radchenko
2024-02-21 10:57 ` Juan Manuel Macías
2024-02-21 12:00 ` Ihor Radchenko
2024-02-21 12:53 10% ` Juan Manuel Macías
2024-02-21 13:10 ` Ihor Radchenko
2024-02-21 14:13 12% ` Juan Manuel Macías
2024-02-21 20:32 ` [proof of concept] inline-special-block (was: [proof of concept] inline language blocks) Juan Manuel Macías
2024-02-22 22:03 13% ` [proof of concept] inline-special-block Juan Manuel Macías
2024-02-21 23:29 12% ` Juan Manuel Macías
2024-02-21 22:11 ` [proof of concept] inline language blocks Samuel Wales
2024-02-21 22:28 13% ` Juan Manuel Macías
2021-06-09 19:35 org-attach a directory? Ypo
2021-06-09 23:39 ` John Kitchin
2021-06-10 3:56 ` Ypo
2021-06-10 12:37 ` Christian Barthel
2021-06-10 14:01 ` Juan Manuel Macías
2021-06-10 16:13 13% ` Juan Manuel Macías
2021-06-07 11:43 literate programming, development log -- ideas? Greg Minshall
2021-06-07 12:00 10% ` Juan Manuel Macías
2023-08-06 12:03 [patch] ox-latex.el: fix blank lines behavior in verse block Juan Manuel Macías
2023-08-07 11:40 ` Ihor Radchenko
2023-08-07 17:23 ` Juan Manuel Macías
2023-08-09 7:57 ` Ihor Radchenko
2023-08-09 8:41 12% ` Juan Manuel Macías
2023-08-10 9:27 ` Ihor Radchenko
2023-08-10 10:39 ` Juan Manuel Macías
2023-08-11 10:00 ` Ihor Radchenko
2023-08-11 18:52 ` Juan Manuel Macías
2023-08-12 7:56 ` Ihor Radchenko
2023-08-12 11:28 10% ` Juan Manuel Macías
2023-08-14 20:10 ` Juan Manuel Macías
2023-08-15 10:08 ` Ihor Radchenko
2023-08-15 11:50 ` Juan Manuel Macías
2023-08-15 11:53 ` Ihor Radchenko
2023-08-15 14:25 11% ` Juan Manuel Macías
2021-06-12 9:15 Write Markdown in Org mode leo
2021-06-12 12:35 ` Juan Manuel Macías
2021-06-12 15:14 ` leo
2021-06-12 15:51 10% ` Juan Manuel Macías
2024-01-22 20:42 Possible LaTeX export bug: Footnotes in items Eric Anderson
2024-01-24 12:11 ` [BUG] Footnotes in section titles Ihor Radchenko
2024-01-24 14:14 ` Max Nikulin
2024-01-24 15:23 12% ` Juan Manuel Macías
2024-01-24 15:31 ` Colin Baxter
2024-01-24 15:41 ` Juan Manuel Macías
2024-01-26 12:53 ` Ihor Radchenko
2024-01-26 13:17 11% ` Juan Manuel Macías
2024-01-26 16:43 ` Max Nikulin
2024-02-01 14:44 ` [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc) (was: [BUG] Footnotes in section titles) Ihor Radchenko
2024-02-01 17:44 ` [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc) Juan Manuel Macías
2024-02-02 17:00 ` Ihor Radchenko
2024-02-02 18:10 13% ` Juan Manuel Macías
2024-02-02 20:21 ` Exporting multiple #+AUTHOR keywords (was: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)) Ihor Radchenko
2024-02-02 22:26 11% ` Exporting multiple #+AUTHOR keywords Juan Manuel Macías
2022-02-22 4:32 Footnote tooltips (an attempt) Juan Manuel Macías
2022-02-22 22:15 11% ` Juan Manuel Macías
2021-01-31 19:37 [patch] to allow org-attach-git to handle individual repositories Juan Manuel Macías
2021-04-28 3:57 ` Bastien
2021-04-28 13:42 10% ` Juan Manuel Macías
2021-04-02 18:15 [Patch] to correctly sort the items with emphasis marks in a list Juan Manuel Macías
2021-04-09 22:28 ` Nicolas Goaziou
2021-04-10 0:01 ` Juan Manuel Macías
2021-04-17 13:27 ` Maxim Nikulin
2021-04-18 17:52 ` Juan Manuel Macías
2021-04-18 21:20 11% ` Juan Manuel Macías
2021-04-10 10:19 ` Nicolas Goaziou
2021-04-10 11:41 ` Juan Manuel Macías
2021-04-13 17:31 ` Maxim Nikulin
2021-04-13 19:08 ` Juan Manuel Macías
2021-04-14 15:42 ` Maxim Nikulin
2021-04-14 17:07 ` Juan Manuel Macías
2021-04-14 21:36 12% ` Juan Manuel Macías
2022-09-18 12:27 [Patch] Pre-/postpend arbitrary LaTeX code to a section Juan Manuel Macías
2022-09-20 13:26 ` Ihor Radchenko
2022-09-20 17:18 10% ` Juan Manuel Macías
2022-09-21 8:55 ` Ihor Radchenko
2022-09-21 14:43 10% ` Juan Manuel Macías
2022-09-22 14:08 ` Ihor Radchenko
2022-09-24 14:50 11% ` Juan Manuel Macías
2022-09-25 3:33 ` Ihor Radchenko
2022-09-25 12:06 10% ` Juan Manuel Macías
2022-09-26 3:56 ` Ihor Radchenko
2022-09-26 7:47 13% ` Juan Manuel Macías
2022-09-21 13:55 ` Daniel Fleischer
2022-09-21 14:51 13% ` Juan Manuel Macías
2024-01-21 8:44 New try at multi-lingual export to latex/pdf using pdflatex and babel Pedro Andres Aranda Gutierrez
2024-01-21 13:02 ` Ihor Radchenko
2024-01-21 17:11 ` Pedro Andres Aranda Gutierrez
2024-02-09 23:10 ` Ihor Radchenko
2024-02-10 6:13 ` Pedro Andres Aranda Gutierrez
2024-02-10 14:39 ` Ihor Radchenko
2024-02-11 6:22 ` Pedro Andres Aranda Gutierrez
2024-02-11 11:04 12% ` Juan Manuel Macías
2020-12-22 17:12 *strong* markup not honored at boundary of macro input during HTML export m27315
2020-12-23 14:58 ` m27315
2020-12-23 15:22 10% ` Juan Manuel Macías
[not found] ` <7e5e7cbe-31d6-2d9e-e450-9c1b54dba95e@gmail.com>
2020-12-23 16:05 10% ` Juan Manuel Macías
2022-09-06 12:25 Agenda 'Org view' (org-projection?) Eduardo Suarez
2022-09-06 14:21 13% ` Juan Manuel Macías
2021-06-18 22:15 publishing: no default publishing function, or symbol is not defined Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 12:48 10% ` Juan Manuel Macías
2023-10-22 21:12 Are 'placement' and 'float' "obsolete terms" in inline images export Juan Manuel Macías
2023-10-23 9:27 ` Ihor Radchenko
2023-10-23 19:00 ` Juan Manuel Macías
2023-10-26 9:14 ` Ihor Radchenko
2024-01-02 21:43 11% ` Juan Manuel Macías
2022-09-27 9:09 Create in Org a bilingual book with facing pages Juan Manuel Macías
2022-09-27 12:29 ` Ihor Radchenko
2022-09-27 16:50 11% ` Juan Manuel Macías
2020-12-28 13:38 Org to ConTeXt exporter? Juan Manuel Macías
2021-01-08 2:37 ` Jason Ross
2021-01-09 17:42 10% ` Juan Manuel Macías
2020-12-28 15:04 ` Marcin Borkowski
2020-12-28 16:23 ` Diego Zamboni
2020-12-28 18:03 10% ` Juan Manuel Macías
2023-09-06 14:55 ox-latex language handling in Org-9.5 vs 9.6 Max Nikulin
2023-09-06 22:20 ` Juan Manuel Macías
2023-09-07 11:50 ` Ihor Radchenko
2023-09-07 14:19 12% ` Juan Manuel Macías
2023-09-07 14:49 ` Max Nikulin
2023-09-08 10:30 ` Max Nikulin
2023-09-08 14:42 10% ` Juan Manuel Macías
2023-09-08 19:02 ` [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6) Juan Manuel Macías
2023-09-09 9:11 ` Ihor Radchenko
2023-09-09 10:36 12% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
2023-09-09 11:33 ` Ihor Radchenko
2023-09-09 23:59 11% ` Juan Manuel Macías
2023-09-10 16:15 ` [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6) Max Nikulin
2023-09-10 16:52 ` Ihor Radchenko
2023-09-10 21:15 10% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
2021-04-03 18:45 How to get a table into a variable in a shell code block? Greg Minshall
2021-04-03 19:01 10% ` Juan Manuel Macías
2021-01-29 16:03 org-attach-git don't automatically commit changes Juan Manuel Macías
2021-01-30 5:10 ` Ihor Radchenko
2021-01-30 13:38 ` Juan Manuel Macías
2021-01-31 3:33 ` Ihor Radchenko
2021-01-31 10:29 ` Juan Manuel Macías
2021-01-31 10:52 ` Ihor Radchenko
2021-01-31 11:41 10% ` Juan Manuel Macías
2021-01-31 13:16 ` Juan Manuel Macías
2021-01-31 13:40 ` Ihor Radchenko
2021-01-31 14:36 10% ` Juan Manuel Macías
2020-11-28 16:59 Remembrance Agents Gerardo Moro
2020-11-28 18:26 ` Jean Louis
2020-11-29 13:07 ` Gerardo Moro
2020-11-29 13:52 ` Eric S Fraga
2020-11-29 17:29 ` Jean Louis
2020-11-29 17:47 ` Eric S Fraga
2020-11-30 11:15 ` Jean Louis
2021-01-06 6:41 ` Possibility to copy text outside EMACS and send it to orgmode document Gerardo Moro
2021-01-06 16:31 10% ` Juan Manuel Macías
2021-02-01 9:10 http links translated to html : target "_blank" Uwe Brauer
2021-02-01 11:03 ` Juan Manuel Macías
2021-02-01 13:56 ` Uwe Brauer
2021-02-01 14:46 ` Juan Manuel Macías
2021-02-01 15:20 ` Uwe Brauer
2021-02-01 21:01 10% ` Juan Manuel Macías
2020-12-08 11:35 Bug: Footnotes on Headers and LaTeX export [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)] Charis Michelakis
2020-12-09 15:06 10% ` Juan Manuel Macías
2021-06-29 11:25 Virtually prefix headlines according to content Rodrigo Morales
2021-06-29 13:34 10% ` Juan Manuel Macías
2022-11-12 14:42 Help with a (query) replacement Ypo
2022-11-12 15:10 ` Juan Manuel Macías
2022-11-12 15:23 12% ` Juan Manuel Macías
2022-11-12 15:12 ` Ypo
2022-11-12 16:04 ` Juan Manuel Macías
2022-11-12 16:29 12% ` Juan Manuel Macías
2023-09-21 7:46 Sanskrit/Devanagari fonts not exported to org-pdf output Zenny
2023-09-21 8:24 13% ` Juan Manuel Macías
2023-09-21 13:46 ` Zenny
2023-09-21 15:33 ` Juan Manuel Macías
2023-09-21 17:53 ` Zenny
2023-09-21 18:28 13% ` Juan Manuel Macías
2023-09-21 18:44 ` Zenny
2023-09-21 19:32 ` Juan Manuel Macías
2023-09-21 20:26 ` Zenny
2023-09-21 20:39 ` Zenny
2023-09-21 20:41 ` Zenny
2023-09-21 21:19 12% ` Juan Manuel Macías
2021-04-30 15:19 How to create a macro that inserts multiline text with :B_ignoreheading: tag? Richard Stanton
2021-04-30 20:40 10% ` Juan Manuel Macías
2023-09-16 18:00 [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword Juan Manuel Macías
2023-09-22 16:38 ` Max Nikulin
2023-09-24 18:42 12% ` Juan Manuel Macías
2023-09-26 19:12 ` Juan Manuel Macías
2023-09-28 10:07 ` Max Nikulin
2023-09-28 15:36 ` AW
2023-10-01 16:02 ` Max Nikulin
2023-10-01 17:48 11% ` Juan Manuel Macías
2024-02-12 10:05 "Full Block" character in example block not visible in Beamer PDF Loris Bennett
2024-02-12 11:06 12% ` Juan Manuel Macías
2022-10-08 14:29 [tip] Create and Insert a public Nextcloud/Owncloud link Juan Manuel Macías
2022-10-09 3:32 ` Max Nikulin
2022-10-09 12:21 11% ` 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 18:37 ` John Kitchin
2021-12-06 10:57 ` Raw Org AST snippets for "impossible" markup Max Nikulin
2021-12-06 15:45 ` Juan Manuel Macías
2021-12-06 16:56 13% ` Juan Manuel Macías
2021-12-08 13:09 ` Max Nikulin
2021-12-08 23:19 ` Juan Manuel Macías
2021-12-08 23:35 ` John Kitchin
2021-12-09 7:01 ` Juan Manuel Macías
2021-12-09 14:56 ` Max Nikulin
2021-12-09 16:11 ` Juan Manuel Macías
2021-12-09 22:27 12% ` Juan Manuel Macías
2021-02-18 16:33 [PATCH] Startup option to separate macros arguments with an alternative string Juan Manuel Macías
2021-04-19 9:19 ` Nicolas Goaziou
2021-04-21 16:01 ` Juan Manuel Macías
2021-04-22 12:55 ` Nicolas Goaziou
2021-04-22 13:46 10% ` Juan Manuel Macías
2022-02-18 0:47 Pandoc and nested emhases Juan Manuel Macías
2023-10-11 16:11 ` Max Nikulin
2023-10-22 19:15 10% ` Juan Manuel Macías
2022-09-19 8:59 Re [Patch] Pre-/postpend arbitrary LaTeX code to a section Pedro Andres Aranda Gutierrez
2022-09-20 13:19 ` Ihor Radchenko
2022-09-20 19:35 12% ` Juan Manuel Macías
2021-10-18 20:37 Unable to configure emacs 27.2 to use org 9.5 Detlef Steuer
2021-10-18 22:28 13% ` 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).