* Re: change the fontsize when exporting to HTML, header not really changed
2022-01-20 17:56 10% ` Juan Manuel Macías
@ 2022-01-20 11:48 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-20 11:48 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe
Uwe Brauer writes:
> Now some text is changed as expected the text in the header not really.
>
> Any idea what would be a more appropriate setting?
Taking into account that h1 is the title, h2, h3, etc. are the classes
for the different header levels. You can put something like this:
#+HTML_HEAD: <style> h2 {font-size:108%}</style>
#+HTML_HEAD: <style> body {font-size:108%}</style>
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: change the fontsize when exporting to HTML, header not really changed
@ 2022-01-20 17:56 10% ` Juan Manuel Macías
2022-01-20 11:48 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-20 17:56 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode, Eric S Fraga
Uwe Brauer writes:
>But it did not work neither. Did you test it? I am on GNU Emacs master
>and git master (ok several weeks old, but still recent enough I'd say)
I hadn't seen Eric's message, but what he says makes a lot of sense: are
you applying a separate style sheet, perhaps with a *.setup document
that already has a header style defined? It looks like one style
overlaps another.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: date format in agenda view
@ 2022-01-28 17:57 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-28 17:57 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe,
Uwe Brauer writes:
> How can I obtain the Spanish week names?
I have this in my init:
#+begin_src emacs-lisp
(setq calendar-week-start-day 1
calendar-day-name-array ["domingo" "lunes" "martes" "miércoles"
"jueves" "viernes" "sábado"]
calendar-month-name-array ["enero" "febrero" "marzo" "abril" "mayo"
"junio" "julio" "agosto" "septiembre"
"octubre" "noviembre" "diciembre"])
#+end_src
(https://www.emacswiki.org/emacs/CalendarLocalization#toc18)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] org-manual.org: update and add info for arbitrary :float values
@ 2022-02-13 22:21 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-13 22:21 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hi Nicolas,
Nicolas Goaziou writes:
> Thanks. Note you need to add two spaces between sentences.
Ah, sorry, I hadn't noticed that :-). The thing is that I have in my
~/.emacs `sentence-end-double-space' set to nil.
> However, isn't it a bug? Shouldn't t value default to "figure"
> environment, if only for the sake of backward compatibility?
I think you're right. t value should be figure and table, I agree. Would
it be appropriate to add these two lines:
In org-latex--inline-image:
((string= float "t") 'figure)
And in org-latex--decorate-table
((string= float "t") "table")
?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Root heading when exporting sub-trees
@ 2022-02-15 12:36 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-15 12:36 UTC (permalink / raw)
To: Michael Dauer; +Cc: orgmode
Hi Michael,
Michael Dauer writes:
> When I export a subtree I normally want to produce a document for the
> topic of the subtree. So I would expect that the contents of the
> subtree would be exported with the heading as title (and maybe file
> name) and the children promoted to level 1.
>
> What I receive is something like this:
> Title: Title of all topics
> 1. Topic
> 1.1
> 1.2
> 1.2.1
> 1.2.3
> 1.3
>
> The whole first level of this outline is pointless.
>
> What is the best way to change this behavior? I mean in
> configuration/patching not by putting the same export properties
> everywhere. But identifying the relevant export properties would be of
> help of course.
You can set specific export properties for a given subtree, for example:
* Subtree
:PROPERTIES:
:EXPORT_OPTIONS: options list
:EXPORT_TITLE: Another title
:EXPORT_FILE_NAME: another file name
:END:
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: table format during html export
@ 2022-02-15 22:16 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-15 22:16 UTC (permalink / raw)
To: Leo Butler; +Cc: orgmode
Hi Leo,
Leo Butler writes:
> Hello,
>
> I have some tables like
>
> | a | b |
> | c | d |
>
> I would like to have this export (in html) to something like
>
> | a b |
> | c d |
>
> i.e., add a vertical bar on the extreme left and right.
>
> I have searched the org manual and online and I can't find a
> solution.
>
> TIA,
> Leo
>
You can modify the attributes for a certain table, for example like this:
#+ATTR_HTML: :border 2 :cellspacing 0 :cellpadding 6 :rules none :frame vsides
| a | b |
| c | d |
For all tables, you can apply a value to
`org-html-table-default-attributes', locally or globally:
#+begin_src emacs-lisp
(setq org-html-table-default-attributes
'(:border "2" :cellspacing "0" :cellpadding "6" :rules "none" :frame "vsides"))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Open a footnote definition outside a narrowed subtree (workaround)
@ 2022-02-22 17:34 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-22 17:34 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Nicolas Goaziou writes:
> The "standard" solution is to use <C-c '>
Thanks fot the tip!
org-edit-special > org-edit-footnote-reference: it's clearly explained
in the docstring, and I've been cloning buffers manually all my life
(facepalm).
Sorry for the noise, naturally the "standard" solution is preferable to my
workaround.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Question Regarding Creating HTML Style Buttons With Org Mode
@ 2022-02-23 2:33 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-23 2:33 UTC (permalink / raw)
To: Samuel Banya; +Cc: orgmode
Hi Samuel,
Samuel Banya writes:
> Hey Juan,
>
> Just wanted to let you know that this works beautifully!
>
> I wish I was as good at Elisp to make this in the first place, but
> this really helps since I wanted to have some minimum overhead for 2
> separate websites to be able to just write in Org Mode but include
> ideas for buttons, with classes and ID values.
>
> This helps a ton, thanks so much as it totally worked! :)
You're welcome! I'm glad it works and is useful to you. Org links
have great potential :-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Footnote tooltips (an attempt)
@ 2022-02-24 16:25 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-24 16:25 UTC (permalink / raw)
To: John Kitchin; +Cc: orgmode
John Kitchin writes:
> that is a nice solution. I probably should have read the docstring on
> org-footnote-get-definition a little more closely, it has the
> definition you need in it!
Well, it's a minor detail. The really brilliant thing here is your idea
of passing the function as a help-echo value, instead of a text string.
It works like a charm! :-).
(I didn't know that the help-echo property could accept a function as a
value, and reading the documentation I realize that this has a lot of
potential...).
Best regards, And thanks again,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: including one double quote in an anonymous footnote?
@ 2022-02-26 14:47 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-26 14:47 UTC (permalink / raw)
To: Greg Minshall; +Cc: orgmode
Hi Greg,
Greg Minshall writes:
> hi. experimenting [after significant confusion!], it appears that
> including a single (unpaired) double quote inside an anonymous footnote
> eliminates the recognition of the footnote. is this intentional?
>
> this works:
> ----
> this is a test.[fn:: a very long footnote]
> ----
>
> whereas this doesn't:
> ----
> this is a test.[fn:: "a very long footnote]
> ----
>
> i notice that for purposes of exporting, i can have the single double
> quote accepted by escaping it with a backslash:
> ----
> this is a test.[fn:: \"a very long footnote]
> ----
> but,
> - the backslash itself shows up in both latex and html exporting
> - the footnote doesn't get displayed in the org buffer as a footnote
> (the separate colors; this is "font locking"?)
>
> Org mode version 9.5.2 (9.5.2-gbb6830 @ /home/minshall/.emacs.d/straight/build/org/)
I can confirm that behavior. One possible solution is to use an entity
(M-x org-entities-help):
this is a test.[fn:: \quot{}a very long footnote]
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: including one double quote in an anonymous footnote?
@ 2022-02-28 20:57 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-28 20:57 UTC (permalink / raw)
To: Greg Minshall; +Cc: orgmode, Nicolas Goaziou
Hi Greg and Nicolas,
Greg Minshall writes:
> Nicolas and Juan Manuel,
>
> thanks very much. the bugfix branch seems to work for my case.
Thank you very much Nicolas. In my case it also works fine.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Filter for HTML (cite) footnotes?
@ 2022-03-08 10:14 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-08 10:14 UTC (permalink / raw)
To: M. ‘quintus’ Gülker; +Cc: orgmode
M. ‘quintus’ Gülker writes:
> That is, what I am after effectively, is post-processing the results
> generated by org-cite resp. citeproc.el. I have names in my
> bibliographic database like “Axel von Hellfeld”, which contain the
> German name particle “von”. Some (not all) citation customs require
> “von” to be abbreviated to “v.” so that the cited name becomes
> “v. Hellfeld”. This is not possible with CSL, so I look for another
> way to automate this during the export process.
I see. Have you tried using `org-export-filter-final-output-functions'?
You can try a find/replace function for the footnotes of final
output. The drawback is that the scope here is broader and
care should be taken with false positives...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Move or rename a file in a link
@ 2022-03-10 14:58 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-10 14:58 UTC (permalink / raw)
To: João Pedro de Amorim Paula; +Cc: orgmode
Hi João, Thanks for your comment.
João Pedro de Amorim Paula writes:
> Thanks for sharing! It'd be great if it worked for attachments as well,
> but that is a whole can of worms.
Regarding attachments, do you mean org attachments or email attachments?
Could you give an example of a use case?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Code blocks and quotes export style
@ 2022-03-14 18:09 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-14 18:09 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> should be even better since, besides LaTeX "\-", HTML exporter uses
> "­" or "­" (I would expect more consistent behavior
> though.)
Hi, Maxim. You're right, I didn't remember that there is a specific
entity in Org for the discretionary hyphen. Sometimes I think too much
from the LaTeX side... :-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: LaTeX export of a file with some accented characters
@ 2022-03-15 20:23 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-15 20:23 UTC (permalink / raw)
To: Vikas Rawal; +Cc: orgmode
Hi Vikas,
Vikas Rawal writes:
> I have an org file with some names (not all) that have accented
> characters. But when I try to export, I get errors such as this:
>
> Sāṅkr - 65190: word not found
>
> What do I do to make Org export these correctly? Is there a way to
> make Org export even if it does not recognise the characters?
Do you have flyspell-mode active? Sounds to me like that's a flyspell
error message, but it's weird anyway and I don't know how to fit it into
your export issue...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: leading superscript on a line for ODT export
@ 2022-03-16 12:03 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-16 12:03 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Hi Eric,
Eric S Fraga writes:
> I need to have a line starting with a superscript, e.g. 1, in an ODT
> exported file. If I write "^1 blah", it doesn't work. I need a
> character before the ^ to have it interpreted as a superscript.
>
> Is there an "empty" character I can use? I tried a non-breaking space
> but that did not work. The space is there but the ^1 gets exported
> literally.
I would use a macro. For example:
#+begin_src emacs-lisp
(defun my-macro-superscript (arg)
(cond ((eq org-export-current-backend 'latex)
(format "@@latex:\\textsuperscript{%s}@@" arg))
((eq org-export-current-backend 'odt)
(format "@@odt:<text:span text:style-name=\"OrgSuperscript\">%s</text:span>@@" arg))))
(setq org-export-global-macros
'(("sup" . "(eval (my-macro-superscript $1))")))
#+end_src
{{{sup(4)}}}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: leading superscript on a line for ODT export
@ 2022-03-16 14:07 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-16 14:07 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode, Eric S Fraga
Max Nikulin writes:
> @@org:@@^1 blah
This is a nice solution. I think a snipet with a "non-existent" backend
would work here too:
@@null:@@^1
(I use a lot export snipets with 'non-existent' backends for inline
comments).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: TOC and latex memoir class
@ 2022-04-02 7:21 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-02 7:21 UTC (permalink / raw)
To: Steve Downey; +Cc: orgmode
Hi Steve,
Steve Downey writes:
> In order to place the table of contents without a section name
> "Contents" the memoir class uses \tableofcontents* rather than
> \tableofcontents.
> However, `org-latex-toc-command` is documented as:
> "LaTeX command to set the table of contents, list of figures, etc.
> This command only applies to the table of contents generated with
> the toc:nil option, not to those generated with #+TOC keyword."
> Which is confusing in two ways, first that toc:nil doesn't generate a
> table of contents, and that it doesn't seem to provide any way of
> getting the string to be used?
>
> As a workaround, I could use the latex command directly, but that
> means not having it available in, for example, an html export.
>
> Is there a workaround I'm missing?
One possible workaround would be to define a macro with a conditional:
if exporting to LaTeX, returns the string 'toc:nil'; otherwise, returns
'toc:t'. And the LaTeX command can be added via a export snippet.
Something like this:
#+MACRO: mytoc (eval (if (eq org-export-current-backend 'latex) "#+OPTIONS: toc:nil" "#+OPTIONS: toc:t"))
{{{mytoc}}}
@@latex:\tableofcontents*@@
* Heading 1
lorem ipsum dolor
* Heading 2
lorem ipsum dolor
------------
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: when exporting latex how to set with in the includegraphics command
@ 2022-04-03 10:19 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-03 10:19 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe,
Uwe Brauer writes:
> But I would like a smaller width say 0.5, how can I achieve that?
#+ATTR_LaTeX: :float nil
#+ATTR_LaTeX: :width <any valid value>
#+CAPTION: El método del Trapecio punto fijo vs PC
[[./diagram-trapfix-vs-trapfixpc-norigid.png]]
(You can add more options to the includegraphics optional argument with
:options attribute; for example, :options scale=.5, etc).
best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] org-element-export-snippet-parser: Fix snippets without ending @@
@ 2022-04-16 10:46 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-16 10:46 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Our current parser recognises the opening "@@html:" as a standalone
> snippet.
>
> Unless I misunderstand something, it is not intentional.
>
> The fix is attached.
This fix makes a lot of sense to me. I've always been intrigued by this
'strange' behavior of html export snippets. Of course, the main danger of
this unintentional behavior is error propagation. I remember seeing it
on a few sites, like here: https://emacs.stackexchange.com/a/30470
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Export LaTeX command inside figure environment
@ 2022-05-08 0:30 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-08 0:30 UTC (permalink / raw)
To: Thomas S. Dye; +Cc: orgmode
Hi, Thomas,
Thomas S. Dye writes:
> Is there a way to add an arbitrary LaTeX command between
> \begin{figure} ... \end{figure} during LaTeX export? I want to end up
> with the following snippet, but can't figure out how to slip in
> \setfloatalignment{b}. \begin{figure}[htb]
> \centering
> \includegraphics[width=.9\linewidth]{hilbertcurves.pdf}
> \caption[Hilbert curves]{\label{fig:orgparagraph1} Hilbert curves of
> various degrees \emph{n}.}
> \setfloatalignment{b}
> \end{figure}
I think the :caption attribute could do the trick (of course everything
must be on one line):
#+ATTR_LaTeX: :caption \caption[Hilbert
curves]{\label{fig:orgparagraph1} Hilbert curves of various degrees
\emph{n}.}\setfloatalignment{b}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] org-attach: Attach current Gnus article parts
@ 2022-05-08 18:06 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-08 18:06 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> I think that a good example implementation is from notmuch.el. It does
> not use anything specific to notmuch, just built-in mm-*.el from gnus:
Thanks for the tip, Ihor. I'll take a look at it, and see if I can
sketch something usable...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: export to latex: begin_example gets exported to verbatim (
@ 2022-05-12 8:52 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-12 8:52 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe,
Uwe Brauer writes:
> Which gets exported to verbatim not lstlisting as I want
Try adding this:
:wrap lstlisting
(I don't use matlab, but I think that should work).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: simple request letter - help
@ 2022-05-13 17:04 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-13 17:04 UTC (permalink / raw)
To: Andrés Ramírez; +Cc: orgmode
Hi Andrés,
Andrés Ramírez writes:
> When I export the file M-x org-export-distpach l p
>
> The second and third paragraph do nat have right alignment as the first
> paragraph.
Can you please copy the contents of your .tex file here: `M-x
org-export-disptatch l l'?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: I can't set dabbrev to respect the writen case
@ 2022-05-14 22:32 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-14 22:32 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Ypo writes:
> Hi
>
> I find dabbrev and fancy-dabbrev very useful to typing fast. But there
> is a problem I am not able to solve: When I apply an expansion while
> writing, the case is always that of the expansion, I can't make it to
> respect what I have written. An example:
>
> — (Typing) "Hel
>
> — (Offered expansion) "hello"
>
> — (What I get when accepting the expansion) "hello"
>
> — (What I wanted) "Hello"
>
> Best regards,
>
> Ypo
>
Take a look at these variables. I have them configured as non-nil:
(setq dabbrev-case-replace t)
(setq dabbrev-case-fold-search t)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: # Comments export
@ 2022-05-30 10:46 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-30 10:46 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Eric S Fraga writes:
> I use drawers for this and then have specific processing of different
> types of drawers, depending on target.
>
> For instance, I might have :note: drawers (similar to inline tasks) with
> the following processing (for odt export; similar for LaTeX):
>
> --8<---------------cut here---------------start------------->8---
> (setq-local org-odt-format-drawer-function
> (lambda (name contents)
> (if (string= name "note")
> (progn
> (format "<text:span text:background=\"#FFFF00\">%s</text:span>" contents)))))
> --8<---------------cut here---------------end--------------->8---
>
> (progn because I used to do more in there...)
I use a special type of footnote, which is exported to LaTeX as pdf
annotations (with the pdfannotate package) and to odt as comments. The
use of footnotes allows me to put comments and annotations within the
paragraph:
https://list.orgmode.org/877de55cjf.fsf@posteo.net/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: About 'inline special blocks'
@ 2022-06-17 19:49 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-17 19:49 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko <yantar92@gmail.com> writes:
> While arbitrary markup can indeed be introduced using our current link
> syntax, there is one important limitation of links:
>
> *** link description cannot contain other links ***
>
> If one seriously tries to extend Org syntax with custom markup elements,
> nested markup will not be possible. And we do not want to change Org
> links to allow other links inside.
>
> Inline special blocks may not have such limitation if we allow special
> blocks to be nested.
+1.
This seems to me a *very* important point.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Keybinding doubt about ARG
@ 2022-06-19 17:21 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-19 17:21 UTC (permalink / raw)
To: Bruno Barbier; +Cc: orgmode
Bruno Barbier writes:
> But, you can easily define your own command.
>
> (defun my-scroll-up-of-1 ()
> (interactive)
> (scroll-up-command 1))
>
> (define-key global-map (kbd "M-n") 'my-scroll-up-of-1)
Or simply doing something like:
(define-key global-map (kbd "M-n") (lambda ()
(interactive)
(scroll-up-command 1)))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Org mode export accessibility
@ 2022-06-26 10:46 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-26 10:46 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross writes:
> As I understand it (which isn't brilliant), the core problem is more to
> do with how the LaTeX/TeX engine processes the input to generate the
> postscript and pdf output. Modern PDFs have a wealth of internal tagging
> which simply sin't supported via the tex -> pdf pathway. The matter is
> made slightly worse by a lack of built-in support within latex/tex for
> accessibility 'tags' (similar to the aria tags for web content).
There is a relatively recent experimental package for LaTeX that may be
of interest to you:
CTAN: https://www.ctan.org/pkg/tagpdf
GitHub: https://github.com/u-fischer/tagpdf
The package is maintained by Ulrike Fischer, who is very active in the
TeX community. However, the package description says:
> The package offers tools to experiment with tagging and accessibility
> using pdfLaTeX and LuaTeX. It isn't meant for production but allows
> the user to try out how difficult it is to tag some structures; to try
> out how much tagging is really needed; to test what else is needed so
> that a pdf works e.g. with a screen reader. Its goal is to get a
> feeling for what has to be done, which kernel changes are needed, how
> packages should be adapted.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Convert a Lisp expression to a tree diagram
@ 2022-06-30 22:30 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-30 22:30 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Invoking search across my notes and archives (all stored in Org, of
> course) yielded the following:
>
> https://reddit.com/r/emacs/comments/u2ca5c/drawtreeel/
> https://reddit.com/r/emacs/comments/kzeyun/pairtree_a_learning_tool_for_visualizing_elisp/
>
> linking to
>
> https://github.com/amno1/draw-cons-tree
> https://github.com/zainab-ali/pair-tree.el (example: https://teddit.namazso.eu/pics/w:2172_vetc0martyb61.png)
>
> Hope it helps.
Thanks a lot, Ihor! There is some very juicy information there.
> actual notes below:
Awesome notes. Hats off to such a detailed capture (reminds me to give
my poor org-capture templates some more love one day :-))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Convert a Lisp expression to a tree diagram
@ 2022-06-30 22:32 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-30 22:32 UTC (permalink / raw)
To: arthur miller; +Cc: orgmode
arthur miller writes:
> This one draws graph of cons cells (lists):
>
> https://github.com/amno1/draw-cons-tree
>
> I never tried with random s-expressions, but I guess you could pass
> them in as lists?
Hi, Arthur,
Thank you for the pointer to draw-cons-tree. I didn't know this package,
I'll take a look.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Convert a Lisp expression to a tree diagram
@ 2022-07-01 10:45 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-01 10:45 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> This capture template is public: https://github.com/yantar92/org-capture-ref
Thank you! It is very complete, and I have seen that it also integrates
with qutebrowser. I'll try it as soon as I have time.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Taking notes of videos in Emacs
@ 2022-07-08 13:25 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-08 13:25 UTC (permalink / raw)
To: Gerardo Moro; +Cc: orgmode
Gerardo Moro writes:
> Hi,
>
> I recently discover the Obsidian Media Extended plugin
> (https://www.youtube.com/watch?v=GQXVWtNkeZw) to take notes while
> watching videos / listening to audios with keybindings to stop the
> video and create timestamps with link to the specific moment of the
> video, etc.
>
> Is there something similar in Emacs?
See org-media-note: https://github.com/yuchen-lea/org-media-note
And, for something simpler, I shared here days ago this code:
https://list.orgmode.org/871qvmt4xr.fsf@posteo.net/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: missing a character / font in agenda?
@ 2022-07-12 17:58 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-12 17:58 UTC (permalink / raw)
To: Daniel Ortmann; +Cc: orgmode
Hi,
Daniel Ortmann writes:
> Any clues where this particular symbol resides? A hint about the
> package name would wonderful. :-)
To be able to display "unusual" symbols in Emacs, I usually use the
symbola font:
You can download it here:
https://fontlibrary.org/en/font/symbola
And then:
(set-fontset-font t 'symbol (font-spec :family "Symbola"))
But I think that what is interesting here is to know how that character
has arrived. Could it be related to some new package you have installed
lately?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [export to CSV]
@ 2022-07-19 11:07 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-19 11:07 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Regards (take care with the heat if you live in Spain (not sure though))
Yes, I live in the Sierra de Madrid, where we are always a few degrees
below Madrid, and these days this is an oven. I guess that you are also
in Spain, because of the mail from the UCM. If so, take care too :-).
Although I think that these days few places in Europe are safe...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: numbering src blocks in HTML export
@ 2022-07-19 15:28 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-19 15:28 UTC (permalink / raw)
To: Fraga, Eric; +Cc: orgmode
Fraga, Eric writes:
> I really do not understand the last paragraph although it implies that
> org already supports adding the line numbers. My elisp-fu is not up to
> scratch to figure this out from the code unfortunately. Would somebody
> explain what to do? Or should I simply add the CSS code that would do
> it for me?
I usually do it this way:
#+begin_src sh -n :exports code
aa
bb
dd
ee
ff
#+end_src
And you can also indicate the number of the first line, ie -n 20
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-23 14:11 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-23 14:11 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Thanks! Considering that the followup discussion deviated from the
> substance of the patch towards related design issues, I have decided to
> marge the patch as is. We can decide on handling AUTO staff later - it
> would be a major change to remove and the details of an alternative are
> not yet worked out.
>
> Applied onto main via 97cfb959d after adding some double spaces
> between sentences and upcasing the beginning of some sentences.
Thanks, Ihor. And sorry again for my typos...
If it's okay with you, I can send another patch with the updated
information in NEWS and the Manual. And we can continue the subsequent
discussion related of babel, polyglossia et alii in another thread.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-23 14:53 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-23 14:53 UTC (permalink / raw)
To: Kai von Fintel; +Cc: orgmode, Ihor Radchenko
Hi Kai,
Kai von Fintel writes:
> I do think that the code on lines 1864 and 1865 of =ox-latex.el=
> (https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ox-latex.el#n1864)
> should not use the old variable names. Since you’ve now defined the
> old variables in =org-compat.el=, my exports work, so I’m ok for the
> moment. But I don’t understand why they are still used in the
> definition of =org-latex--format-spec=.
I think you're right. My bad, sorry for that: I have not accounted for
`org-latex--format-spec' in my patch. I will send a new patch soon to fix
this.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals
@ 2022-10-04 20:28 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-04 20:28 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Fraga, Eric, Max Nikulin, emacs-orgmode@gnu.org
Ihor Radchenko writes:
> If I were to choose an alternative symbol other than "_", I'd choose
> "@":
>
> @name{<contents>}
> @name{{<contents}}
> @name[:key value ...]{<contents>}
>
> 1. It is similar to Texinfo
> 2. It does not clash with TeX
> 3. We already use @ in the inline export snippets.
I like the "@" alternative a lot. And I agree with all three points. It is
also compact without losing clarity, and does not give the feeling of a
blank space before, as in the case of "_".
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Interest in an Org video meetup?
@ 2022-10-06 20:09 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-06 20:09 UTC (permalink / raw)
To: Russell Adams; +Cc: orgmode
Russell Adams writes:
> Would there be any interest in a monthly 1-2 hour long ad-hoc screen
> sharing and video discussion for Org-mode?
>
> I'm offering to schedule and moderate the first few events. I'd
> propose a Saturday meeting in the afternoon European time to cover EU
> and NA.
>
> I'm considering using Jitsi, or maybe GNU Jami.
>
> Topics could include Q&A, demonstrations of features, interactive
> troubleshooting, etc. I hadn't considered presentations, but
> that could be an option too.
>
> Comments?
Great idea. I would like to participate, even if it was just to listen
:-) But I'm afraid that these months I'm going to have horrible
schedules. Is it planned to record these meetings?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: watch YT videos through in Emacs [Was: Interest in an Org video meetup?]
@ 2022-10-07 13:17 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-07 13:17 UTC (permalink / raw)
To: Quiliro Ordóñez; +Cc: emacs-orgmode
Hola, Quirilo,
Quiliro Ordóñez writes:
>> There is the YouTube option, which I imagine no one would like (me
>> neither). The only thing in its favor is that Invidious can be used to
>> watch the videos. BTW, I watch YT videos through Invidious in Emacs,
>> with the Ytel package and EMMS/MPV.
>
> Nice. Is there a guide to do this specificly?
I have written a bunch of homemade hacks for ytel, including the ability
to display video thumbnails in the results. I explain all the details on
my blog, here:
https://gnutas.juanmanuelmacias.com/ytel_invidious.html
The post is in Spanish. If anyone is interested in this topic, I can
write a version in English.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Best android app
@ 2022-10-14 18:52 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-14 18:52 UTC (permalink / raw)
To: Renato Pontefice; +Cc: emacs-orgmode
Renato Pontefice writes:
> Sorry…I just realize that I’ve not tell for what I’m looking for the best application…. :-(
>
> It’s for open .org file!
> I would see my org-mode file I’ve created on my emacs on my Mac and check every things…
If you want to have a (more or less) complete Emacs/Org experience, my
recommendation is that you install Termux and install Emacs in Termux.
To get a working and updated version, better install it from F-droid.
There was a thread here recently about termux and org:
https://list.orgmode.org/87pmkfnh90.fsf@posteo.net/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Line breaks and brackets in LaTeX export
@ 2022-10-22 12:26 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-22 12:26 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Or, to be completely safe, we can introduce a defcustom that will
> control such clean-up (clean up by default).
>
> I propose the following:
> 1. Merge my patch with \\[0pt] safe page breaks
> 2. Modify org-latex-template to replace unnecessary occurrences of
> "\\[0pt]" in CONTENTS when org-latex-compact-latex (you may propose
> other defcustom names) is non-nil.
>
> WDYT?
+1
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [off-topic] E-readers and Org-Mode
@ 2022-10-24 14:11 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-24 14:11 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: Org Mode List
Pedro Andres Aranda Gutierrez writes:
> My workflow is to create an HTML from the org file(s) and then
> generate an EPUB2 file forthe reader (in my case Kobo or Cervantes
> Light) I have always felt the rendition is much more confortable than
> PDF. Other readers may be better suited for PDF.
Thanks, Pedro. BTW, have you tried org-epub
(http://github.com/ofosos/org-epub)? I don't usually work with epubs,
but the few times that I need to export to epub it usually works for me.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Org mode, Org Mode, Org-mode or Org-Mode?
@ 2022-10-28 20:55 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-28 20:55 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: Org-Mode mailing list
Marcin Borkowski writes:
> What is the "official" version? I found at least two spelling on
> orgmode.org...
Interesting question. When I don't write carelessly I try to write "Org
Mode", but it's more out of habit. The wikipedia entry says "Org-mode".
The Google entry for orgmode.org says "Org mode", however the title of
the website says "Org Mode".
I imagine this disparity is also shared by other famous Emacs modes,
where you see them written in various ways...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Cannot find therefore at 972 character...
@ 2022-10-29 12:57 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-29 12:57 UTC (permalink / raw)
To: Renato Pontefice; +Cc: emacs-orgmode
Renato Pontefice writes:
> I tried ib more way, but I’m unable to see where the error is.
>
> Can you help me? Please
>
> Renato
>
> Otherwise I haver to put away all that I’ve done and restart from0
Renato, can you please put the content of your
/Users/renatopontefice/.emacs.d/init.el file here? (copy and paste). Of
course, if your file has sensitive information like passwords and such,
don't forget to remove that before posting it here).
As you've already been told, there's an error in your file, but we can't
help you if we don't see it.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [correction]
@ 2022-10-31 12:22 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-31 12:22 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> I see, thanks. Last most likely trivial question, where, in which file
> does filetags save the relevant information, i.e tags
I haven't looked at the code, but I imagine that the information is
stored in the variables I mentioned before, when you use a controlled
vocabulary for the tags. You can also store them in a .filetags file.
See: https://github.com/DerBeutlin/filetags.el#usage
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [correction]
@ 2022-10-31 15:08 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-31 15:08 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> - "_&&_" seems to be ok but I am not entirely sure about it
"&&" will give you trouble if you manipulate the file in a shell,
because it will be understood as the '&&' operator. You would have to
use escape characters.
Maybe "@@" or "%%" are safer choices. Look at this screenshot:
https://i.imgur.com/eGXepU3.png
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [correction]
@ 2022-10-31 17:35 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-31 17:35 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Still gets displayed as
> my-auctex-init_ftag_emacs.el
>
> What do I miss?
You're right, sorry. I'm afraid I was too hasty and the code from the
other message, as I put it, will never work :-).
You can test how it looks, however, if you evaluate the function in a
dired buffer, but the moment you revert the buffer the overlay is lost,
as expected.
That has to be solved in another way. Perhaps some code from the
all-the-icons-dired package can be reused.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Help with a (query) replacement
@ 2022-11-12 15:10 10% ` Juan Manuel Macías
2022-11-12 15:23 12% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-12 15:10 UTC (permalink / raw)
To: Ypo; +Cc: Org-mode
Ypo writes:
> Hi
>
> I am copy-pasting e-books into org-mode to read and study them.
>
> Usually, words come hyphenated, like "ato- mized", that I wanted to
> transform into "atomized".
>
> I am trying with query replace, but I am starting to think that it is
> not the correct tool for this job.
> I tried "query-replace [a-z]-" but I don't know how to exclude the
> letter before the "-".
>
> What would you advise?
I think it will be more practical for you to use pandoc:
With this command you can convert an epub format to org:
pandoc my-epub.epub -o my.epub.org
(https://pandoc.org)
You can also install calibre and convert your epubs to plain text from
there.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] ox-latex: fix `org-latex-guess-babel-language'
@ 2022-11-17 14:48 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-17 14:48 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi, Ihor, sorry for the late replay,
Ihor Radchenko writes:
>> If the user puts a string other than AUTO as an argument to
>> `\babelprovide', it gives an error when exporting. For example:
>>
>> `#+LaTeX_Header: \babelprovide[<options>]{hebrew}'
>>
>> I am attaching a patch to fix that behaviour.
>
> Thanks!
> Could you also add a test to testing/lisp/test-ox-latex.el?
I'm afraid I'm not going to be able to do it in the short term, because
these days I'm going through a serious family problem, my mother is
admitted to the hospital, and I don't think I'm going to have time to
attend to this list.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
@ 2023-09-22 8:00 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-22 8:00 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> Exactly done as you advised, but no pdf is produced even after waiting
> for ~10minutes (attached screenshot)
Let's try the following:
1. Export your document to a 'your-document.tex' file: C-c C-e l l
2. Open a terminal in your directory and run:
latexmk -f -pdf -lualatex -interaction=nonstopmode your-document.tex
(a pdf would have to be created after compilation. If there are any
errors, please copy your-document.log here).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: #+LATEX_HEADER: \usepackage[greek,german]{babel} ??
@ 2024-01-16 19:46 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-16 19:46 UTC (permalink / raw)
To: Horst Leps; +Cc: emacs-orgmode@gnu.org
Horst Leps writes:
> % Created 2024-01-16 Tue 20:00
> % Intended LaTeX compiler: pdflatex
> \documentclass{scrartcl}
> \usepackage[utf8]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{graphicx}
> \usepackage{grffile}
> \usepackage{longtable}
> \usepackage{wrapfig}
> \usepackage{rotating}
> \usepackage[normalem]{ulem}
> \usepackage{amsmath}
> \usepackage{textcomp}
> \usepackage{amssymb}
> \usepackage{capt-of}
> \usepackage{hyperref}
> \usepackage[germanb]{babel}
> \usepackage[utf8]{inputenc}
> \usepackage[LGR,T1]{fontenc}
> \usepackage[greek,german]{babel}
> \author{HL}
The document loads babel twice:
\usepackage[germanb]{babel} <==
\usepackage[utf8]{inputenc}
\usepackage[LGR,T1]{fontenc}
\usepackage[greek,german]{babel} <==
Hence the 'option class for package babel' error. You have loaded babel
in your org document with the [greek,german] option and (probably, in
the class you are loading) babel is already loaded as well.
Try:
#+LaTeX_Header: \PassOptionsToPackage{greek,german}{babel}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [DISCUSSION] Add "Recent News" to orgmode.org
@ 2024-02-04 20:24 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-04 20:24 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode, Sacha Chua, Bastien, Timothy
Ihor Radchenko writes:
> Hi,
>
> What do you think about an idea to modify Org mode front page
> (https://orgmode.org/), adding the most recent blog posts and
> discussions about Org mode?
>
> We might use Org-related records from Sacha's news and/or
> https://planet.emacslife.com/ as a source, scrape it regularly (once per
> day/week or on every export), and embed the relevant links into the
> orgweb/index.html
>
> This way, visitors can easily see how active Org mode community is and
> discover Org-related blogs/forums.
+1
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [patch] ox.latex.el: Add missing character warnings
@ 2024-02-12 19:17 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-12 19:17 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Sorry, the previous patch was incomplete. The attached patch is correct.
>
> When I try the patch with a simple file like
>
> Hello. 你好。
>
> I do not see any warnings or errors indicated.
How weird... And don't they at least appear in the *Messages* buffer?
With your example, they appear to me with pdfLaTeX, lualatex and XelaTeX
(I have used the default value of org-latex-pdf-process):
https://i.imgur.com/OPOpH5c.png
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: A question about local/experimental branches
@ 2024-02-27 9:57 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-27 9:57 UTC (permalink / raw)
To: Bastien Guerry; +Cc: Ihor Radchenko, orgmode
Hi, Bastien,
Bastien Guerry writes:
> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> AFAIU, Juan does not have write access to savannah.
>> Should we give it? Of course, if he is willing to use savannah. Any
>> other public repo is also fine.
>
> Juan, let me know if you need access:
> https://orgmode.org/worg/org-contribute.html#devs
Thank you! I think for the moment I will use GitLab to publish my
experimental branch, if it is not essential to do it in savannah (I am
more used to gitlab). As soon as I publish it, I'll share the
link.
Best regards,
Juan Manuel
^ 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%]
* 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: 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: 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] 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: [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: 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: `: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: 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%]
* [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%]
* [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%]
* 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 11% ` 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 11% ` 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 11%]
* 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
1 sibling, 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] 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: [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: `: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, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-19 9:51 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías writes:
> If you want to pass the class or id 'manually' to each link, and thus
> have more control, you can evaluate this other version, where the class
> or id would be added at the end of the link description, after (for
> example) "!style":
PS: Sorry, this is the correct code:
(org-link-set-parameters "button"
:face '(:foreground "green4" :underline t)
:follow (lambda (path) (browse-url path))
:export (lambda (path desc backend)
(when (eq backend 'html)
(let ((style (if (string-match "\\(!style\\)\\(.+\\)" desc)
(match-string 2 desc)
""))
(desc (replace-regexp-in-string "\\(!style .+\\)" "" desc)))
(format "<form><button %s
formaction=\"%s\">%s</button></form>" style
path desc)))))
Example:
[[button:http://www.sambanya.com/artgallery.html][Art Gallery Page Link !style class="mybutton"]]
== HTML ==>
<p>
<form><button class="mybutton" formaction="http://www.sambanya.com/artgallery.html">Art Gallery Page Link </button></form>
</p>
^ permalink raw reply [relevance 12%]
* Re: [Question] 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%]
* 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%]
* 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: 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%]
* 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: [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: [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: 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: [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: Help with a (query) replacement
2022-11-12 15:10 10% ` Juan Manuel Macías
@ 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: [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: 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] 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: 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] 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: [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: 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: 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: 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 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 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-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-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-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: `: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: `: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%]
* 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, 1 reply; 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, 1 reply; 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-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, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-02 13:47 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Fraga, Eric, Max Nikulin, emacs-orgmode@gnu.org
Ihor Radchenko writes:
> _name{<contents>}
> _name{{<contents>}} <--- extra {} is added as needed for escaping
> _name[:key value ...]{<contents>}
>
> The syntax idea is to follow the relevance between [[links]] and [cite:citations]
> but here we have src_name[...]{...} and _name[...]{<contents>} instead.
And how about this:
%_name{<contents>}
%_name{{<contents>}} <--- extra {} is added as needed for escaping
%_name[:key value ...]{<contents>}
or any other symbol instead of "%" ?
N.B.: I must admit this is more for an "aesthetic" reason. Although
perhaps it can be useful to search in the documents.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: org-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: [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, 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: [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: 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: 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: [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: 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: [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: [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: [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: 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: 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: 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: [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: 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: 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: [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: 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: 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: 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: [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: 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: `: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-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%]
* 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%]
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
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
[not found] <E1ocmvz-0002iB-2M@fencepost.gnu.org>
2022-09-30 3:31 ` [HELP] Fwd: Org format as a new standard source format for GNU manuals Ihor Radchenko
2022-09-30 12:49 ` Max Nikulin
2022-10-01 3:30 ` Ihor Radchenko
2022-10-01 10:42 ` Max Nikulin
2022-10-01 11:01 ` Ihor Radchenko
2022-10-01 11:27 ` Max Nikulin
2022-10-02 4:59 ` Ihor Radchenko
2022-10-02 10:38 ` Fraga, Eric
2022-10-02 13:02 ` Ihor Radchenko
2022-10-02 13:47 13% ` Juan Manuel Macías
2022-10-03 4:23 ` Ihor Radchenko
2022-10-04 20:28 10% ` 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-12-08 20:03 12% Making a dictionary in Org 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
2022-10-15 15:14 12% Doubts about a function for my org-capture template 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
2024-01-02 23:46 11% [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export Juan Manuel Macías
2024-02-08 22:13 11% Link type for pdf-tools annotations Juan Manuel Macías
2024-02-09 12:13 ` Irfan S
2024-02-09 12:48 13% ` Juan Manuel Macías
2024-02-08 23:25 ` Ihor Radchenko
2024-02-09 0:40 11% ` 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-02-26 8:43 ` Bastien Guerry
2024-02-26 11:06 ` Ihor Radchenko
2024-02-26 13:03 ` Bastien Guerry
2024-02-27 9:57 10% ` 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
2022-10-18 4:39 ` Ihor Radchenko
2022-10-19 17:12 ` Max Nikulin
2022-10-20 5:07 ` Ihor Radchenko
2022-10-20 17:15 ` Max Nikulin
2022-10-21 3:41 ` Ihor Radchenko
2022-10-21 16:32 ` Max Nikulin
2022-10-22 5:15 ` Ihor Radchenko
2022-10-22 12:26 10% ` Juan Manuel Macías
2024-03-22 1:04 11% [bug] Smart quotes: confusion of apostrophe with second level quotes 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 11% ` Juan Manuel Macías
2024-02-12 18:26 ` Ihor Radchenko
2024-02-12 19:17 10% ` 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
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-10-22 15:01 10% [tip] Export some footnotes as pdf annotations (LaTeX) or comments (odt) Juan Manuel Macías
[not found] <mailman.57.1645549224.6185.emacs-orgmode@gnu.org>
2022-02-22 22:30 ` Footnote tooltips (an attempt) Ypo
2022-02-23 2:26 ` Juan Manuel Macías
[not found] ` <CAJcAo8tsK5o+789Wv=i6ddiSrM4fDyX8HCvjAgDLXGyLXWRWmQ@mail.gmail.com>
2022-02-23 19:52 ` Juan Manuel Macías
2022-02-23 22:05 ` John Kitchin
2022-02-24 2:04 ` Juan Manuel Macías
2022-02-24 13:01 ` John Kitchin
2022-02-24 16:25 10% ` 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
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
2022-09-27 1:48 org exported pdf files Jude DaShiell
2022-09-27 2:48 ` Ihor Radchenko
2022-09-27 3:15 ` Jude DaShiell
2022-09-27 3:24 ` Ihor Radchenko
2022-09-27 4:31 ` Jude DaShiell
2022-09-27 4:58 ` Ihor Radchenko
2022-09-28 4:36 ` Jude DaShiell
2022-09-28 4:53 ` Timothy
2022-09-28 6:48 ` Jude DaShiell
2022-09-28 8:47 ` Tim Cross
2022-09-28 9:19 ` Timothy
2022-09-28 17:08 ` Tim Cross
2022-09-28 18:23 12% ` Juan Manuel Macías
2022-02-15 20:48 table format during html export Leo Butler
2022-02-15 22:16 10% ` Juan Manuel Macías
2022-07-12 17:18 missing a character / font in agenda? Daniel Ortmann
2022-07-12 17:58 10% ` 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-01-28 17:41 date format in agenda view Uwe Brauer
2022-01-28 17:57 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
2022-05-14 19:58 I can't set dabbrev to respect the writen case Ypo
2022-05-14 22:32 10% ` Juan Manuel Macías
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
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-07-23 13:44 BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Kai von Fintel
2022-07-23 13:59 ` Ihor Radchenko
2022-07-23 14:07 ` Kai von Fintel
2022-07-23 14:22 ` Ihor Radchenko
2022-07-23 14:39 ` Kai von Fintel
2022-07-23 14:53 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
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
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
2022-06-19 15:50 Keybinding doubt about ARG Ypo
2022-06-19 16:49 ` Bruno Barbier
2022-06-19 17:21 10% ` Juan Manuel Macías
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
2022-10-14 18:16 Best android app Renato Pontefice
2022-10-14 18:37 ` Renato Pontefice
2022-10-14 18:52 10% ` Juan Manuel Macías
2022-02-11 20:37 [PATCH] org-manual.org: update and add info for arbitrary :float values Juan Manuel Macías
2022-02-13 21:18 ` Nicolas Goaziou
2022-02-13 22:21 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
2024-03-01 20:34 Experimental public branch for inline special blocks Juan Manuel Macías
2024-03-02 8:29 ` Stefan Nobis
2024-03-02 10:57 13% ` 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
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-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-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-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
2021-03-22 21:59 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
2022-10-28 20:24 Org mode, Org Mode, Org-mode or Org-Mode? Marcin Borkowski
2022-10-28 20:55 10% ` Juan Manuel Macías
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
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
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
2022-05-23 21:06 About 'inline special blocks' Juan Manuel Macías
2022-05-24 2:36 ` Tim Cross
2022-05-24 3:56 ` Ihor Radchenko
2022-06-17 6:28 ` Ihor Radchenko
2022-06-17 19:49 10% ` Juan Manuel Macías
2022-01-20 8:43 change the fontsize when exporting to HTML, header not really changed Uwe Brauer
2022-01-20 17:56 10% ` Juan Manuel Macías
2022-01-20 11:48 10% ` 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
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
2022-04-16 5:17 [PATCH] org-element-export-snippet-parser: Fix snippets without ending @@ Ihor Radchenko
2022-04-16 10:46 10% ` Juan Manuel Macías
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-14 15:12 ` Max Nikulin
2022-07-14 15:53 ` Juan Manuel Macías
2022-07-14 18:17 10% ` Juan Manuel Macías
2022-07-17 9:55 ` Ihor Radchenko
2022-07-19 15:01 ` Juan Manuel Macías
2022-07-23 5:01 ` Ihor Radchenko
2022-07-23 14:11 10% ` 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-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-02-26 14:33 including one double quote in an anonymous footnote? Greg Minshall
2022-02-26 14:47 10% ` Juan Manuel Macías
2022-02-26 15:00 ` Greg Minshall
2022-02-26 19:20 ` Juan Manuel Macías
2022-02-28 14:47 ` Nicolas Goaziou
2022-02-28 18:36 ` Greg Minshall
2022-02-28 20:57 10% ` Juan Manuel Macías
2022-06-30 14:19 Convert a Lisp expression to a tree diagram Juan Manuel Macías
2022-06-30 15:17 ` Ihor Radchenko
2022-06-30 22:30 10% ` Juan Manuel Macías
2022-07-01 1:13 ` Ihor Radchenko
2022-07-01 10:45 10% ` Juan Manuel Macías
2022-06-30 16:21 ` arthur miller
2022-06-30 22:32 10% ` Juan Manuel Macías
2022-02-22 16:04 Open a footnote definition outside a narrowed subtree (workaround) Juan Manuel Macías
2022-02-22 16:45 ` Nicolas Goaziou
2022-02-22 17:34 10% ` Juan Manuel Macías
2021-06-03 21:11 [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
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
2022-09-18 12:27 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
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
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
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
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
2022-02-21 0:38 ` Samuel Banya
2022-02-23 2:25 ` Samuel Banya
2022-02-23 2:33 10% ` Juan Manuel Macías
2022-04-03 9:18 when exporting latex how to set with in the includegraphics command Uwe Brauer
2022-04-03 10:19 10% ` Juan Manuel Macías
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
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
2022-05-28 14:58 # Comments export Ypo
2022-05-28 15:44 ` Timothy
2022-05-28 15:58 ` Ypo
2022-05-28 16:05 ` Timothy
2022-05-28 23:15 ` Samuel Wales
2022-05-29 0:46 ` Ypo
2022-05-30 7:35 ` Eric S Fraga
2022-05-30 10:46 10% ` Juan Manuel Macías
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
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-10-29 12:08 Cannot find therefore at 972 character Renato Pontefice
2022-10-29 12:57 10% ` Juan Manuel Macías
2022-02-15 10:23 Root heading when exporting sub-trees Michael Dauer
2022-02-15 12:36 10% ` Juan Manuel Macías
2022-04-01 23:22 TOC and latex memoir class Steve Downey
2022-04-02 7:21 10% ` Juan Manuel Macías
2022-03-15 3:28 LaTeX export of a file with some accented characters Vikas Rawal
2022-03-15 20:23 10% ` Juan Manuel Macías
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
2022-02-22 4:32 Footnote tooltips (an attempt) Juan Manuel Macías
2022-02-22 22:15 11% ` Juan Manuel Macías
2022-07-08 13:03 Taking notes of videos in Emacs Gerardo Moro
2022-07-08 13:25 10% ` Juan Manuel Macías
2021-03-17 20:29 Syntax Proposal: Multi-line Table Cells/Text Wrapping Atlas Cove
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 ` 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
2022-07-18 6:57 org-table with different conventions: decimals Uwe Brauer
2022-07-18 23:02 ` Juan Manuel Macías
2022-07-19 6:20 ` [export to CSV] (was: org-table with different conventions: decimals) Uwe Brauer
2022-07-19 11:07 10% ` [export to CSV] Juan Manuel Macías
2022-05-12 7:13 export to latex: begin_example gets exported to verbatim ( Uwe Brauer
2022-05-12 7:31 ` Eric S Fraga
2022-05-12 8:05 ` Uwe Brauer
2022-05-12 8:52 10% ` Juan Manuel Macías
2022-11-12 14:42 Help with a (query) replacement Ypo
2022-11-12 15:10 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
2022-10-30 9:49 org-fstree.el overview over directories (but no comments are possible) Uwe Brauer
2022-10-30 12:52 ` Juan Manuel Macías
2022-10-30 13:10 ` Uwe Brauer
2022-10-30 13:56 ` Juan Manuel Macías
2022-10-30 17:16 ` Uwe Brauer
2022-10-30 18:17 ` Juan Manuel Macías
2022-10-30 18:48 ` Uwe Brauer
2022-10-30 19:04 ` Juan Manuel Macías
2022-10-30 19:21 ` Uwe Brauer
2022-10-30 19:26 ` [correction] (was: org-fstree.el overview over directories (but no comments are possible)) Uwe Brauer
2022-10-30 19:51 ` [correction] Juan Manuel Macías
2022-10-30 21:23 ` [correction] Uwe Brauer
2022-10-31 12:22 10% ` [correction] Juan Manuel Macías
2022-10-31 12:55 ` [correction] Uwe Brauer
2022-10-31 15:08 10% ` [correction] Juan Manuel Macías
2022-10-31 15:48 ` [correction] Uwe Brauer
2022-10-31 16:23 ` [correction] Juan Manuel Macías
2022-10-31 16:58 ` [correction] Uwe Brauer
2022-10-31 17:35 10% ` [correction] Juan Manuel Macías
2022-05-07 23:43 Export LaTeX command inside figure environment Thomas S. Dye
2022-05-08 0:30 10% ` Juan Manuel Macías
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
2022-09-13 15:54 error org export to pdf when latex letter class has been added to org-latex-classes M. Pger
2022-09-13 17:55 13% ` Juan Manuel Macías
2022-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-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
2022-07-19 15:00 numbering src blocks in HTML export Fraga, Eric
2022-07-19 15:28 10% ` Juan Manuel Macías
2022-03-13 10:54 Code blocks and quotes export style Sébastien Gendre
2022-03-13 16:06 ` Kaushal Modi
2022-03-13 18:39 ` Juan Manuel Macías
2022-03-14 12:50 ` Max Nikulin
2022-03-14 18:09 10% ` 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-05-13 16:37 simple request letter - help Andrés Ramírez
2022-05-13 17:04 10% ` 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
2022-03-05 19:58 Move or rename a file in a link Juan Manuel Macías
2022-03-09 20:30 ` João Pedro de Amorim Paula
2022-03-10 14:58 10% ` Juan Manuel Macías
2024-02-04 19:41 [DISCUSSION] Add "Recent News" to orgmode.org Ihor Radchenko
2024-02-04 20:24 10% ` Juan Manuel Macías
2022-11-14 22:46 [PATCH] ox-latex: fix `org-latex-guess-babel-language' Juan Manuel Macías
2022-11-15 1:54 ` Ihor Radchenko
2022-11-17 14:48 10% ` 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
2022-08-28 15:37 Have all the tags of a heading, with a tag hierarchy Cletip Cletip
2022-08-28 16:21 13% ` Juan Manuel Macías
2022-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
2022-10-06 13:20 Interest in an Org video meetup? Russell Adams
2022-10-06 20:09 10% ` Juan Manuel Macías
2022-10-07 1:43 ` Ihor Radchenko
2022-10-07 1:47 ` Russell Adams
2022-10-07 10:37 13% ` Juan Manuel Macías
2022-10-07 11:28 ` watch YT videos through in Emacs [Was: Interest in an Org video meetup?] Quiliro Ordóñez
2022-10-07 13:17 10% ` Juan Manuel Macías
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
2023-09-22 7:04 ` Zenny
2023-09-22 8:00 10% ` Juan Manuel Macías
2022-03-16 11:23 leading superscript on a line for ODT export Eric S Fraga
2022-03-16 12:03 10% ` Juan Manuel Macías
2022-03-16 13:46 ` Max Nikulin
2022-03-16 14:07 10% ` Juan Manuel Macías
2024-01-12 10:24 Tableofcontents Horst Leps
2024-01-12 16:53 ` Tableofcontents Tory S. Anderson
2024-01-13 12:27 ` Tableofcontents Ihor Radchenko
2024-01-16 19:12 ` #+LATEX_HEADER: \usepackage[greek,german]{babel} ?? Horst Leps
2024-01-16 19:46 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
2022-05-07 14:31 [PATCH] org-attach: Attach current Gnus article parts Juan Manuel Macías
2022-05-08 12:30 ` Ihor Radchenko
2022-05-08 13:23 ` Juan Manuel Macías
2022-05-08 14:18 ` Ihor Radchenko
2022-05-08 18:06 10% ` Juan Manuel Macías
2022-10-24 7:12 [off-topic] E-readers and Org-Mode Pedro Andres Aranda Gutierrez
2022-10-24 14:11 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
2022-03-05 15:40 Filter for HTML footnotes? M. ‘quintus’ Gülker
2022-03-06 4:03 ` Juan Manuel Macías
2022-03-08 7:40 ` Filter for HTML (cite) footnotes? M. ‘quintus’ Gülker
2022-03-08 10:14 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-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
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
2022-05-23 14:30 About 'inline special blocks' Juan Manuel Macías
2022-05-23 15:20 ` Kaushal Modi
2022-06-19 12:47 ` Juan Manuel Macías
2022-06-20 16:57 ` Max Nikulin
2022-06-20 22:46 ` Tim Cross
2022-06-26 4:07 ` Org mode export accessibility (was: About 'inline special blocks') Ihor Radchenko
2022-06-26 6:29 ` Tim Cross
2022-06-26 10:46 10% ` Org mode export accessibility 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).