* [tip] Export annotations with the 'Mindflow' LaTeX package
@ 2021-05-10 7:19 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-10 7:19 UTC (permalink / raw)
To: orgmode
Hi all,
A new LaTeX package, mindflow, has recently been uploaded to CTAN
(https://www.ctan.org/pkg/mindflow), which I found interesting and
useful for my org workflow. With this package we can add annotations and
ideas to our document. I mean, all that is in a `mindflow'
environment (including entire sections) will appear as in a kind of
'draft mode', with different format and colour. There is a global option
that allows you to choose between showing or not showing those
annotations.
I think it can be useful (for example) to export custom Org drawers to
that environment. But it also occurred to me to write the following, to
export a entire tree as a `mindflow' environment, with the tag
`:annotation:'
#+begin_src emacs-lisp
(defun my-org-add-mindflow-env-heading (backend)
(when (eq backend 'latex)
(org-show-all)
(save-excursion
(goto-char (point-min))
(while (re-search-forward org-heading-regexp nil t)
(let ((element (org-element-at-point)))
(when (member "annotation" (org-element-property :tags element))
(save-restriction
(org-narrow-to-subtree)
(save-excursion
(goto-char (point-min))
(insert "\n\n@@latex:\\begin{mindflow}@@\n\n")
(goto-char (point-max))
(insert "\n\n@@latex:\\end{mindflow}@@\n\n")))))))))
(add-hook 'org-export-before-processing-hook #'my-org-add-mindflow-env-heading)
#+end_src
Here are some screenshots: https://imgur.com/a/jo320AI
Best regards,
Juan Manuel
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 8%]
* Re: Org-attach for a directory
[not found] ` <CAPHku6O3RojzhaSu3d2pWfnE8x7N_9WAfjCupHyKcxNyD-i=ew@mail.gmail.com>
@ 2022-06-09 10:11 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-09 10:11 UTC (permalink / raw)
To: Cletip Cletip; +Cc: orgmode
Cletip Cletip writes:
> Thank you for your answer.
You're welcome.
> Your answer seems perfect to answer my question: I modify a function
> of org-mode, and it allows me to attach folders and files to a
> heading.
> Unfortunately, it doesn't work (probably because of my version of
> org-mode I guess)
>
> I have the following error:
> make-directory: The file exists:
> /home/user/sharedDirectoryPrivate/notes/braindump/.data/11e080/1b-7896-4f20-a24a-b9f45337e940
I don't know all the details of your problem. But if it gives you an
error saying The file exists, I would say that the cause is that the
directory you want to copy already exists in your attach folder. Could
it be that in your case? Note that the 'copy-directory' function does not
overwrite copied directories.
> Just to make sure I understood correctly: you can, with the "copy"
> method and the simple modification of the "org-attach-attach"
> function, attach a folder to a heading of org mode?
> If so, this is exactly what I am looking for, and this would be a
> great help.
Exactly. I wrote a new version of org-attach-attach, modified that part,
as I told you, and added it via advice-add (with :override keyword) so
that it overrides the old function.
> To clarify my second question, I would like to have a folder system
> with org-mode, and therefore only use org-attach to arrange my
> documents, exactly like you.
> Could you describe your workflow in more detail? Your use of tags for
> example, do you put dates, etc.
Now I have less time than I would like to go into the details, but
perhaps some reflections that I shared here may be useful to you:
https://list.orgmode.org/875yms7wys.fsf@posteo.net/
The strong point of my approach is to think of Org nodes and not the
classic directory/file scheme. But for that to work well you must rely
on a system that ensures a semantic search through the nodes. For me the
answer is org-ql (and if you're a helm user, you have helm-org-ql too).
Basically it's turning all your Org documents into a human-readable
database, where searches can be narrowed down by tags, status, content,
etc.
Another important point is that this scheme works wonderfully well with
org-capture.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: format/fill of text in a cell in tables
@ 2021-12-18 11:09 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-18 11:09 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> I think, one attempt could be to use org-edit-special, to edit a cell,
> type the text in a temporary buffer, fill it and then return to the table.
>
> That seems so obvious that I think there might be technical problems,
> because otherwise it would have been implemented already.
I proposed that here the last time a similar discussion came up, but now
I don't think it's a good idea. I believe the root problem is that the
visual representation of the tables in Org is line oriented. Cells with
a lot of content (paragraphs, for example) should be shrunken, because
the content is a single line; when editing each cell in its special
buffer, that content would have to be converted into paragraphs, and
when saving the edition buffer, convert it back to a single line again.
I tried to write something similar for my personal use, but it is very
tricky. Maybe such an implementation would work better for AUCTeX, since
tables in LaTeX are not line oriented.
About a possible solution for Org regarding the topic of 'complex'
tables, I have ended up giving up. I think it is better to create the
complex tables in raw LaTeX. To export them to HTML you could perhaps
think of a LaTeX block that would return the results compiling with
tex4ht (https://ctan.org/pkg/tex4ht?lang=en) instead of LaTeX. But I
don't know if it would work. The point is that anything other than a
simple and clean table (visually speaking) in Org, is to enter the land
of the tricks.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* [tip] search this mailing list with helm-surfraw
@ 2021-04-05 9:25 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-05 9:25 UTC (permalink / raw)
To: orgmode
Hi all,
I am a fanatic Helm user, and within Helm I make intensive use of
helm-surfraw. It is necessary to install Surfraw on the system (in Arch
it is in the community repository). For who does not know, Surfraw
(https://en.wikipedia.org/wiki/Surfraw) is a script written by Julian
Assange that lets you perform searches across many engines and internet
sites. Every kind of search is controlled by a set of scripts called
elvi. We can also write our custom elvis, and save them in the
~/.config/surfraw/elvi/ folder. I have written some elvis for my
personal use, among them this simple script to search this mailing list,
which I share here in case someone finds it useful:
#+begin_src sh :shebang #!/bin/sh :tangle ~/.config/surfraw/elvi/orgmode-ml
# DESC: search Org Mode mailing list archives
# elvis: orgmode-ml -- Search Org Mode mailing list archives (https://lists.gnu.org/archive/html/emacs-orgmode/)
. surfraw || exit 1
w3_usage_hook () {
cat <<EOF
Usage: $w3_argv0 [search words]...
Description:
Search in Org Mode mailing list (https://lists.gnu.org/archive/html/emacs-orgmode/)
EOF
w3_global_usage
}
w3_config
w3_parse_args "$@"
if test -z "$w3_args"; then
w3_browse_url "https://lists.gnu.org/archive/html/emacs-orgmode/"
else
escaped_args=`w3_url_of_arg $w3_args`
w3_browse_url "https://lists.gnu.org/archive/cgi-bin/namazu.cgi?idxname=emacs-orgmode&sort=score&result=normal&max=20&submit=Search!&query=${escaped_args}"
fi
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* On zero width spaces and Org syntax
@ 2021-12-03 12:48 8% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-03 12:48 UTC (permalink / raw)
To: orgmode
Hi all,
It is usually recommended, as you know, to insert a zero width space
character (Unicode U+200B) as a sort of delimiter mark to solve the
scenarios of emphasis within a word (for example, =/meta/literature=)
and others contexts where emphasis marks are not recognized (for example
=[/literature/]=). I believe that as a puntual workaround it is not bad;
however, I find it problematic that this character is part, more or less
de facto, of the Org syntax. For two main reasons:
1. It is an invisible character, and therefore it is difficult to
control and manage. I think it is not good practice to introduce this
type of characters implicitly in a plain text document.
2. It is more natural that this type of space characters are part of the
'output' and not of the 'input'. In the input it is better to introduce
them not implicitly but through their representation. For example, in
LaTeX (with LuaTeX) using the command '\char"200B{}' (or '^^^^200b'),
'​' in HTML, etc.
In any case, as an implicit character, I do not see it appropriate for
the syntax of a markup language. The marks should be simply ascii
characters, IMHO. So what if Org had a specific delimiter mark for the
scenarios described above? For example, something like that:
#+begin_example
/meta/''literature
*meta*''literature
[''*literature*'']
#+end_example
WDYT?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [PATCH] Add new entity \-- serving as markup separator/escape symbol
@ 2022-07-29 0:32 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-29 0:32 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi, Ihor,
Ihor Radchenko writes:
> Given the raised objections, zero-width space does not appear to be a
> useful escape symbol because it has its valid uses as a standalone space
> symbol.
>
> The raised objections can be solved using some kind of intricate
> heuristics, but I do not feel like it is a good direction to go. The
> code will be too complex and fragile.
>
> Therefore, I am proposing a different approach for shielding
> fontification: introducing a special entity.
>
> The new entity is \--, which is a valid boundary between emphasis
> markup. It will be removed during export (replaced by "").
>
> "\--" specifically is somewhat arbitrary choice. The actual requirements
> for the entity name are: (1) No clash with LaTeX (which is why simpler
> \- would not cut it); (2) Being a valid markup boundary: entity must end
> with (any space ?- ?\( ?' ?\" ?\{).
>
> I am attaching a tentative patch introducing the new entity. Note that
> some minor tweaks to the parser were needed. I do not see it as a big
> deal - the current entity regexp has much more cumbersome exceptions.
>
> Also, the patch will not work correctly on org → org export, similar to
> pointed in one of the replies to the previous abandoned approach. I do
> not want to address it here because a much more appropriate solution for
> this issue is changing org-element-interpret-data.
>
> Consider (org-element-interpret-data '("asd" (bold () "bold") "bsd"))
> This will return "asd*bold*bsd", which is not correct even though the
> given Org datum is not wrong by itself - such things can easily appear
> when user filters are applied to parse tree during org→org export.
>
> Otherwise, the patch should be good enough to play around and kick-start
> the discussion.
I'm late joining this thread, although I am particularly interested in
the topic.
I can't make any technical comments because I haven't had time to test
the patch yet, but I have to say that your idea of using a special
entity seems to me the best approach to the problem. I would vote for
this to be the way to go.
I believe that using the zero width space character as an escape
character is not a happy idea, and I have already left my arguments in
some other thread, long ago. The zero width space is a random
workaround, but should not (in my opinion) be part of the markup. For
various reasons: it is not an ascii character, there are certain
contexts in which it can produce an unexpected result in LaTeX, etc. In
addition, the zero width space, as an escape character, has a curious
anomaly: it is an escape character that does not have a plan B and a way
to escape the escape character when you want to use it by itself.
I also like the idea of using a special entity because it is not
necessary to invent anything new and it takes advantage of an existing
resource.
Well, that's my opinion.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: text after sub headings?
@ 2021-12-26 9:17 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-26 9:17 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]
Max Nikulin writes:
> It is not necessary complex layout. It is a decoration similar to
> pictures in fiction books. Unlike figures such additions are not
> strictly important to understand material. In printed form it is like
> figures however. Insets are appropriate in particular places, but
> tolerate some shift due to paging.
Generally, any scenario where graphic and textual content must be
distributed and managed is already complex layout. Although there are
several levels of complexity, and in many cases visual control is
necessary. In any case, TeX is not intended for (stricto sensu) layout
but for typesetting, which is where DTP programs often fail. This does
not mean that highly complex pages cannot be achieved in TeX, but the
strong point of TeX is the automation of processes and repeated
structures, while the strong point of DTP programs is visual layout
design, more focused on magazines, newspapers, posters, etc. There are
"intermediate places", and in TeX there are still unresolved issues. For
example: the possibility of working with independent text flows (for
example, create two parallel TeX processes: one for even pages and
another for odd pages) or grid typesetting (in LaTeX it is almost impossible
and in ConTeXt some advances have been made) although I am very critical
of the grid composition, which has become a plague lately.
Anyway, in order not to get too off the topic, here are a couple of
examples that I made (one of them with flowfram), exporting an inline
task to LaTeX through an ad hoc filter:
https://i.imgur.com/8ERXNWp.png
https://i.imgur.com/mpFRL9h.png
(code attached)
Best regards,
Juan Manuel
[-- Attachment #2: tests.org --]
[-- Type: application/vnd.lotus-organizer, Size: 16218 bytes --]
^ permalink raw reply [relevance 8%]
* Open a footnote definition outside a narrowed subtree (workaround)
@ 2022-02-22 16:04 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-22 16:04 UTC (permalink / raw)
To: orgmode
Hi all,
When I am working on a narrowed subtree and want to open a footnote for
editing (`C-c C-o': `org-open-at-point'), I get the message: "Definition
is outside narrowed part of buffer". I don't know if there is a
"standard" solution for that (aside from cloning the buffer and/or
removing the restrictions)... I’ve written this simple and quick
workaround, and then remapped `C-c C-o' so that:
`C-u C-c C-o'
my function
`C-c C-o'
`org-open-at-point'
┌────
│ (defun my-org-open-fn-indirect-buffer ()
│ (interactive)
│ (if (not (equal (org-element-type (org-element-context)) 'footnote-reference))
│ (error "Not in a footnote reference!")
│ (let* ((el (org-element-context))
│ (label (org-element-property :label el))
│ (buf (buffer-name))
│ (format (format "%s | Note %s" buf label)))
│ (when (get-buffer format)
│ (kill-buffer format))
│ (clone-indirect-buffer format t)
│ (setq header-line-format (format "NOTE %s" label))
│ (widen)
│ (org-open-at-point)
│ (recenter 0))))
│
│ (defun my-org-open-at-point ()
│ (interactive)
│ (if (equal current-prefix-arg nil)
│ (org-open-at-point)
│ (my-org-open-fn-indirect-buffer)))
│
│ (with-eval-after-load 'org
│ (define-key org-mode-map (kbd "C-c C-o") nil)
│ (define-key org-mode-map (kbd "C-c C-o") 'my-org-open-at-point))
└────
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* [patch] ox-latex.el: fix blank lines behavior in verse block
@ 2023-08-06 12:03 8% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-06 12:03 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 3441 bytes --]
Rationale for this patch: the treatment of blank lines in
`org-latex-verse-block' is inconsistent with the syntax of the `verse'
environment, both the one that includes LaTeX and the one provided by
the `verse' package as a replacement for the former.
Currently, each blank line is exported to LaTeX as an explicit vertical
space: \vspace*{1em}. This can return unexpected results. For example,
this:
┌────
│ #+begin_verse
│
│ lorem
│ ipsum
│ dolor
|
│ #+end_verse
└────
is exported to LaTeX as:
┌────
│ \begin{verse}
│ \vspace*{1em}
│ lorem\\[0pt]
│ ipsum\\[0pt]
│ dolor\\[0pt]
│ \vspace*{1em}
│ \end{verse}
└────
In the LaTeX `verse' environment, spaces before and after the content
are not taken into account.
As for the separation between stanzas, this is marked with at least one
blank line between the stanzas, as in normal paragraphs (not with an
explicit vertical space). Also it is not necessar y that the last verse
of each stanza ends with the linebreak mark `\\'.
So, after this patch:
• Any blank line before and/or after the content is removed;
• One or more blank lines between stanzas are exported as a single blank
line, leaving the previous final verse without the linebreak mark
`\\';
• When verse numbering is enabled via the `:lines' attribute (for the
`verse' package), the last verses of each stanza are marked with
`\\!', according to the verse package syntax (this was not necessary
with the previous behavior).
This way, the `verse' block is exported to LaTeX with the correct
syntax. This also brings the advantage of being able to globally control
the spacing between stanzas via the verse package’s \stanzaskip command.
Example:
┌────
│ #+begin_verse
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│ #+end_verse
└────
LaTeX:
┌────
│ \begin{verse}
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ \end{verse}
└────
And with verse numbers:
┌────
│ #+ATTR_LaTeX: :lines 5
│ #+begin_verse
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│ #+end_verse
└────
LaTeX:
┌────
│ \begin{verse}
│ \poemlines{5}
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\!
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\!
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ \end{verse}
│ \poemlines{0}
└────
N.B.: the `\\[0pt]' mark of the last verse does not affect the final result.
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-fix-blank-lines-behavior-in-verse-b.patch --]
[-- Type: text/x-patch, Size: 1944 bytes --]
From 0c8a352567333d0d743b5235b68e9cd5d513f615 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 6 Aug 2023 12:42:36 +0200
Subject: [PATCH] lisp/ox-latex.el: fix blank lines behavior in verse block
export.
* (org-latex-verse-block): now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package.
---
lisp/ox-latex.el | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..26827537a 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4128,20 +4128,28 @@ contextual information."
verse-block
;; In a verse environment, add a line break to each newline
;; character and change each white space at beginning of a line
- ;; into a space of 1 em. Also change each blank line with
- ;; a vertical space of 1 em.
+ ;; into a space of 1 em. One or more blank lines between lines
+ ;; are exported as a single blank line.
(format "%s\\begin{verse}%s\n%s\\end{verse}%s"
vwidth
attr
(replace-regexp-in-string
"^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
(replace-regexp-in-string
- (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")
- "\\vspace*{1em}"
+ (concat "\\("
+ (regexp-quote org-latex-line-break-safe)
+ "\n\\)"
+ "\\(^[ \t]*"
+ (regexp-quote org-latex-line-break-safe)
+ "\n"
+ "\\)+")
+ (if lin "\\\\!\n\n" "\n\n")
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n"
(concat org-latex-line-break-safe "\n")
- contents nil t)
+ ;; Remove any blank lines before and after CONTENTS.
+ (concat (org-trim contents t) "\n")
+ nil t)
nil t)
nil t)
linreset)
--
2.41.0
^ permalink raw reply related [relevance 8%]
* Re: idea for capture anywhere in x
@ 2022-10-12 14:22 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-12 14:22 UTC (permalink / raw)
To: Ypo; +Cc: Ihor Radchenko, bugs, Org-mode
Ypo writes:
> The first workflow would consist in emphasizing the web page
> permanently:
I think what you are looking for is something similar to what certain
extensions for firefox or chrome do, like highlighter. It's useful, but
I'd say only for static pages.
> 1. Open in ~eww~ the web page.
As long as the webpage doesn't (unfortunately) use javascript.
> 2. Emphasize with org-mode: highlight the text of the web page.
> 3. In the future, when opening again the web page, the highlights
> should appear.
It wouldn't be too hard (I think) to implement something for shr or eww,
so that overlays would be applied to highlight the text in eww-mode, and
the position info would be saved somewhere, so that eww would retrieve
it on page reload. As Ihor has recommended to you, org-remark could have
a (possible) use there. I would investigate on that side; also with
org-remark you could associate notes in org-mode.
> I don't know what would be the best way to do it. The only way I know
> similar to that, is using "org-web-tools-insert-web-page-as-entry".
It seems safer to me to save the content of a page in one way or
another, because that page may one day cease to be online. org-web-tools
is a great tool. The only drawback I find is that pandoc conversions
from html to org are not always very clean (depends on the page you want
to save). To the above could be added the possibility of highlighting
the content of the page and saving everything locally, to later read the
page offline in eww-mode.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* [tip] Go to the org node from the attached directory
@ 2021-10-07 14:57 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-07 14:57 UTC (permalink / raw)
To: orgmode
Hi,
I often come across the following use case:
helm-locate leads me to a file named (for example) document.pdf, which
is in an attached folder of an Org node. I open the document and then I
would like to jump from there to the Org node. I don't know if anyone
has found any solutions for this or if there is any specific package. I
have come up with this poor man's solution: add a local variable to the
attached directory, which should contain the org node ID.
The function that adds the variable after I run org-attach:
#+begin_src emacs-lisp
(defun my-org-attach/add-dir-variable (&rest _ignore)
(let* ((dir (org-attach-dir))
(id (org-id-get-create))
(default-directory dir))
(unless (file-exists-p (concat dir "/" ".dir-locals.el"))
(save-window-excursion
(add-dir-local-variable nil 'node-id id)
(save-buffer)
(read (current-buffer))
(kill-buffer)))))
#+end_src
and then:
#+begin_src emacs-lisp
(advice-add 'org-attach :after #'my-org-attach/add-dir-variable)
#+end_src
and the function to jump from the attached folder to the org node:
#+begin_src emacs-lisp
(defun my-org-attach/goto-node ()
(interactive)
(org-id-goto node-id))
#+end_src
(of course this only works if there is only one attached directory per
node).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Fallback fonts in LaTeX export for non latin scripts
@ 2023-09-06 14:58 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-06 14:58 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode, Ihor Radchenko
Ihor Radchenko writes:
> Do I understand correctly that onchar=id will not break anything if text
> is correctly marked with \selectlanguage{<lang>}?
To load language features (hyphen rules, captions, etc.) there is no
problem. But to load a font associated with a language, the font of the
last declared language will always be loaded. Well, it is not a problem,
because if in a document there are texts in Russian and Bulgarian, for
example, the natural thing is that they go in the same font, since both
languages share the Cyrillic script. But there may be cases when the
author needs different fonts. In such a case, the user should not use
the onchar = etc property:
https://i.imgur.com/vmsCNkP.png
In any case (to organize myself mentally) I thought that it could be
done on two levels:
- Level 0: The fonts associated with each script are loaded (from a
defcustom list) if luatex is the current engine. And low-level code is
generated in Lua with the luaotfload.add_fallback function. That code
can be in a Lua file or directly within the preamble, enclosed in the
\directlua primitive (mode=harf means that HarfBuzz is used as otf
rendering):
\directlua
{luaotfload.add_fallback("orgfallback",
{
"oldstandard:mode=harf;script=grek;",
"oldstandard:mode=harf;script=cyrl;",
"freeserif:mode=harf;script=arab;",
"freeserif:mode=harf;script=dev2;",
etc., etc.
})
}
And, to load the fallback fonts:
\setmainfont{latinmodernroman}[RawFeature={fallback=orgfallback}]
At this level per-language properties are not loaded, but at least
readability is ensured. The user cannot modify the fonts associated
with each script within the document, but can modify, of course, the
defcustom.
- Level 1: The user can load language properties and associate fonts
with each language using Babel's high-level code (via keywords in Org,
as we have commented in previous messages). Here you can also modify
the default fonts (also, as we mentioned before): main, mono, sans and
math. If the language is declared with an asterisk (for example:
russian*) the onchar=etc property will be included in the preamble,
and it would not be necessary to switch to russian explicitly. It is
assumed that in this scenario the only language with Cyrillic script
would be Russian. For language swithcing, in the rest of the cases,
some babel command would have to be used using @@latex:@@, special
blocks, etc. When Org already has its own language switching
mechanism, this would be used instead. Wdyt?
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 8%]
* Re: "Orgdown", the new name for the syntax of Org-mode
@ 2021-11-28 22:25 8% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-11-28 22:25 UTC (permalink / raw)
To: orgmode
Hi,
I believe (IMHO) that it does not make much sense to separately name the
Org Mode syntax (as a markup language). That would only generate
confusion among users. Furthermore, 'Org Mode', as a whole, is already a
sufficiently recognized and popular name, even outside the GNU Emacs
community. A single name is best remembered. More than one name means
atomization. For example: there is TeX (the typographic engine) and TeX
(the programming language for that engine). And there has never been any
conflict.
On the other hand, drawing a dividing line between Org (a lightweight
markup language) and Org (a GNU Emacs major mode) as if both things
could exist separately is an illusory exercise. I mean, that the
Org's global experience is the fusion of both things.
I migrated from Markdown to Org Mode a long time ago not because I was
looking for a new and best lightweight markup language but because Org
provides me with a complete and quite sophisticated and productive work
environment. An environment that includes, yes, its own syntax, but all
within Emacs, which is where makes sense. I do not know if it is an
emergent quality, but I see Org, in many ways (and with all its
synapses) as an interface for Emacs.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Multilingual quotes inside paragraphs
@ 2021-07-28 13:49 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-28 13:49 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim, thank you for your comments.
Maxim Nikulin writes:
> Are you intentionally avoiding macros {{{lang(ru, текст)}}}?
Yes. Precisely, these experiments are just an attempt to find an
alternative to macros (I use macros a lot). In scenarios like these
(chunks of text) is where the issue of the comma as a escape character
in macros becomes more evident (this comma issue has been discussed in a
past thread, and some interesting proposals were made). Links and
macros, of course, have their pros and cons.
> It seems, you are abusing links a bit.
I'm afraid it's true :-). Anyway I think the links have a great
potential. I have tried exploring other "eccentric" uses of links, for
example here (to export subfigures to LaTeX and HTML):
https://orgmode.org/list/87mty1an66.fsf@posteo.net/ or also in my
org-critical-edition package, to work on (philological) critical
editions from Org: https://gitlab.com/maciaschain/org-critical-edition
> [...]
> Another issue is that someone will almost immediately want to put such
> quote inside link or vice versa to make some fragment of a quote a
> regular link.
Yes, that issue you describe would be one of the biggest drawbacks for
the use of links in these contexts.
Links (or macros) are a good user-level solution to solve certain
specific cases, IMHO. At a native level (in case Org someday implement
consistent and native multilingual support), I don't know what would be
the best solution for multilingual chunks of text inside paragraphs.
Maybe some kind of inline `quote' block?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Org inside LaTeX (a poor man's approach with LuaTeX)
@ 2022-06-25 3:10 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-25 3:10 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]
Hi all,
I know some old school LaTeX users who are interested in giving Org a
try, but seem to have a hard time getting out of their LaTeX comfort
zone. So I thought maybe it wouldn't be a bad idea to invite them to try
some Org doses without leaving LaTeX. I got the idea from the LaTeX
markdown package... With one drastic difference: the markdown package
includes a complete LaTeX markdown parser. Mine is just a poor man hack
that runs emacs --batch through Lua.
For example, you can put things like this in a LaTeX document:
\begin{luacode*}
org = [[
* Section
/Lorem ipsum dolor/
*Lorem ipsum dolor*
#+caption: Lorem ipsum dolor
#+ATTR_LaTeX: :booktabs t
|-------------+-------------+-------------|
| lorem | ipsum | dolor |
|-------------+-------------+-------------|
| lorem ipsum | lorem ipsum | lorem ipsum |
| lorem ipsum | lorem ipsum | lorem ipsum |
| lorem ipsum | lorem ipsum | lorem ipsum |
| lorem ipsum | lorem ipsum | lorem ipsum |
|-------------+-------------+-------------|
| lorem ipsum | lorem ipsum | lorem ipsum |
|-------------+-------------+-------------|
]]
org_output()
\end{luacode*}
Unfortunately I've only gotten it to work this way explicitly. If I try
to define a macro or environment to make it simpler, it returns errors
everywhere.
If anyone wants to try it, I am attaching to this email a 'test.tex'
document that contains everything you need. You just have to compile it
with lualatex.
Best regards and happy weekend,
Juan Manuel
[-- Attachment #2: test.tex --]
[-- Type: application/x-tex, Size: 1541 bytes --]
^ permalink raw reply [relevance 8%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
@ 2021-05-25 12:42 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-25 12:42 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]
Hi Nicolas,
Thank you for your indications. Attached the updated patch.
Do you need me to prepare another patch to document the modifications
and add them to org-NEWS?
Best regards,
Juan Manuel
Nicolas Goaziou writes:
> Hello,
>
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
>
> Thank you. Some comments follow.
>
>> +(defcustom org-latex-default-quote-environment "quote"
>> + "Default environment used to `quote' environment."
>
> --> Default environment used for "quote" blocks.
>
>> + :group 'org-export-latex
>> + :version "24.4"
>> + :package-version '(Org . "8.0")
>
> You can remove the :version keyword. And :package-version is wrong.
>
>> + :type 'string)
>
> You also need to add :safe t
>
>> (defcustom org-latex-default-table-mode 'table
>> "Default mode for tables.
>>
>> @@ -2895,9 +2903,17 @@ channel."
>> "Transcode a QUOTE-BLOCK element from Org to LaTeX.
>> CONTENTS holds the contents of the block. INFO is a plist
>> holding contextual information."
>> + (let* ((env (org-export-read-attribute :attr_latex quote-block :environment))
>> + (opt (org-export-read-attribute :attr_latex quote-block :options))
>> + (current-env (if env env org-latex-default-quote-environment))
>> + (current-opt (if opt opt "")))
>
> We don't use global variables directly as above, but use
>
> (plist-get info :latex-default-quote-environment)
>
> instead. This could be written as
>
>
> (let ((environment
> (or (org-export-read-attribute :attr_latex quote-block :environment)
> (plist-get info :latex-default-quote-environment)))
> (options
> (or (org-export-read-attribute :attr_latex quote-block :options)
> "")))
> ...)
>
> Could you send an updated patch?
>
> Regards,
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-latex.el-add-LaTeX-attributes-to-quote-block_updated.patch --]
[-- Type: text/x-patch, Size: 2348 bytes --]
From eea6956e1baa07c9a9753ed71be48a1e962442a9 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 25 May 2021 14:02:06 +0200
Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
* lisp/ox-latex.el (latex): add `org-latex-default-quote-environment' to `:options-alist'
(org-latex-default-quote-environment): the default quote environment
is `quote'
(org-latex-quote-block): add two attributes: `environment' and `options'
---
lisp/ox-latex.el | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index b9ecf070a..c4f2c6f53 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -121,6 +121,7 @@
(:latex-classes nil nil org-latex-classes)
(:latex-default-figure-position nil nil org-latex-default-figure-position)
(:latex-default-table-environment nil nil org-latex-default-table-environment)
+ (:latex-default-quote-environment nil nil org-latex-default-quote-environment)
(:latex-default-table-mode nil nil org-latex-default-table-mode)
(:latex-diary-timestamp-format nil nil org-latex-diary-timestamp-format)
(:latex-footnote-defined-format nil nil org-latex-footnote-defined-format)
@@ -772,6 +773,13 @@ default we use here encompasses both."
:package-version '(Org . "8.0")
:type 'string)
+(defcustom org-latex-default-quote-environment "quote"
+ "Default environment used to `quote' blocks."
+ :group 'org-export-latex
+ :package-version '(Org . "9.5")
+ :type 'string
+ :safe t)
+
(defcustom org-latex-default-table-mode 'table
"Default mode for tables.
@@ -2895,10 +2903,19 @@ channel."
"Transcode a QUOTE-BLOCK element from Org to LaTeX.
CONTENTS holds the contents of the block. INFO is a plist
holding contextual information."
+ (let ((environment
+ (or (org-export-read-attribute :attr_latex quote-block :environment)
+ (plist-get info :latex-default-quote-environment)))
+ (options
+ (or (org-export-read-attribute :attr_latex quote-block :options)
+ "")))
(org-latex--wrap-label
- quote-block (format "\\begin{quote}\n%s\\end{quote}" contents) info))
-
+ quote-block (format "\\begin{%s}%s\n%s\\end{%s}"
+ environment
+ options
+ contents
+ environment)
+ info)))
;;;; Radio Target
--
2.31.1
^ permalink raw reply related [relevance 8%]
* Re: puzzled about :fit for LaTeX src block
@ 2022-01-13 15:41 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-13 15:41 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Eric S Fraga writes:
> This did it! Thank you. I am curious now to find out what tool was
> used instead... something for later today!
Well, it seems that if you use ":imagemagick yes", the image is created
with the `org-babel-latex-convert-pdf' function. I almost always use this
to create images from latex blocks, for example:
#+begin_src latex: imagemagick yes :iminoptions -density 600
\bfseries Hello world!
#+end_src
":fit" crop the image, but you can also put in your "org-format-latex-header" "\\documentclass[varwidth]{standalone}"
On the contrary, without :imagemagick, but with results to *.png file,
`org-create-formula-image' is used, which depends on
"org-preview-latex-process-alist" and
"org-preview-latex-default-process". Since I only use LuaTeX for
everything, I have this in my init, in order to preview LaTeX fragments:
(setq luamagick
'(luamagick
:programs ("lualatex" "convert")
:description "pdf > png"
:message "you need to install lualatex and imagemagick."
:use-xcolor t
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.0 . 1.0)
:latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
(add-to-list 'org-preview-latex-process-alist luamagick)
(setq org-preview-latex-default-process 'luamagick)
Note that the -trim option for the "convert" program (last line) allows
you to crop the image from the pdf page.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [PATCH] speed commands: error message when a key is not associated with a command
@ 2022-04-30 14:41 8% ` Juan Manuel Macías
2022-04-30 19:39 8% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-30 14:41 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Note that speed commands are not only decided by
> org-speed-command-activate. Any function in org-speed-command-hook can
> trigger speed command. Throwing an error in org-speed-command-activate
> can potentially shadow other functions in the hook.
Ah, I see... I had not taken into account what you mention.
But, if I have understood correctly how this hook works, each associated
function has its "independence", right? I mean, if I have
org-speed-command-activate and org-babel-speed-command-activate
associated to this hook, and I bind the "K" key to an action in
org-babel-key-bindings, but that key does not is associated with any
action in org-speed-commands, then the error message would only be
displayed in the proper context, that is, if I hit K at the beginning of
the headline or any location defined for org-use-speed-commands.
Another possibility I can think of is, instead of returning an error
message: just do nothing when a wrong key is pressed. Something, maybe,
like this (I suppose that the same should be done in each function added
to the hook):
...
(let ((defined (cdr (assoc keys
;; FIXME: don't check `org-speed-commands-user' past 9.6
(if (boundp 'org-speed-commands-user)
(append org-speed-commands
org-speed-commands-user)
org-speed-commands)))))
(if defined defined
'ignore))))
I don't know if this would avoid unexpected results...
what do you think?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: org-mode export to (latex) PDF
@ 2021-07-13 17:53 8% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-13 17:53 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim,
Maxim Nikulin writes:
> I do not know if new engines allows to get list of available fonts and
> to choose a set of fonts with better coverage than lmodern.
LuaTeX and XeTeX use harfbuzz as OpenType rendering engine. On
LuaLaTeX and XeLaTeX you must use the fontspec package
(https://www.ctan.org/pkg/fontspec) to load otf or ttf fonts and add
opentype features. It is very powerful and its interface is very simple
to use. XeTeX has access to system fonts. LuaTeX has access to both
system fonts and any font you want to declare, simply by adding the
path.
For example:
\setmainfont{Palatino Linotype}[Ligatures=NoCommon,Numbers=Lowercase]
With LuaTeX you can also define new opentype features on the fly using
scripts in Lua, via the function fonts.handlers.otf.addfeature
For example, here I define a character substitution:
\directlua{
fonts.handlers.otf.addfeature{
name = "mysub",
type = "substitution",
data = {
periodcentered = "anoteleia",
},
}
}
And here I add that feature to Linux Libertine font:
\setmainfont{Linux Libertine O}[RawFeature=+mysub]
For multilingual management I recommend using Babel instead of
Polyglossia. You can, for example, assign with Babel families from fonts
and language definitions to non-Latin scripts (Cyrillic, Greek,
Devanagari, Arabic, etc.). For example
\babelprovide[onchar=ids fonts,hyphenrules=russian]{russian}
\babelprovide[onchar=ids fonts,hyphenrules=ancientgreek]{greek}
\babelfont[russian]{rm}[%
Numbers=Lowercase]{Linux Libertine O}
\babelfont[greek]{rm}[%
Numbers=Lowercase]{Old Standard}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [PATCH] speed commands: error message when a key is not associated with a command
2022-04-30 14:41 8% ` Juan Manuel Macías
@ 2022-04-30 19:39 8% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-30 19:39 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
> Ihor Radchenko writes:
>
>> Note that speed commands are not only decided by
>> org-speed-command-activate. Any function in org-speed-command-hook can
>> trigger speed command. Throwing an error in org-speed-command-activate
>> can potentially shadow other functions in the hook.
This other, more general solution has also occurred to me, although I
don't know if it's too tricky :-). The idea is to define an
org-speed-command-strict-hook. Something like this (I haven't tested it
much), and probably have its drawbacks:
#+begin_src emacs-lisp
(defcustom org-speed-command-strict-hook
nil
"TODO"
:group 'org-structure
:version "24.1"
:type 'hook)
(defun org-speed-command-strict-function (_)
(pcase (run-hook-with-args-until-success 'org-speed-command-strict-hook _)
('nil (error "Command not defined: \"?\" for help"))
(symbol (run-hook-with-args-until-success 'org-speed-command-strict-hook _))))
;; no strict speed commands (default values):
;; org-speed-command-strict-hook: nil
;; org-speed-command-hook: (org-speed-command-activate org-babel-speed-command-activate)
;; when strict speed commands:
(setq org-speed-command-strict-hook '(org-speed-command-activate org-babel-speed-command-activate))
(setq org-speed-command-hook '(org-speed-command-strict-function))
(defun my-org-toggle-speed-commands ()
(interactive)
(if org-use-speed-commands
(progn
(setq org-use-speed-commands-on org-use-speed-commands)
(setq org-use-speed-commands nil)
(message "speed commands off"))
(setq org-use-speed-commands org-use-speed-commands-on)
(message "speed commands on")))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [tip] Export and open a PDF in Android via Termux
@ 2022-05-19 18:01 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-19 18:01 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Eric S Fraga writes:
> Same with me. I have to have a smartphone as our institution made the
> decision to remove all landlines and have all staff use MS Teams as our
> work "phone". I use termux to give me access to Emacs + org so that I
> at least get some real use out of the "smart"phone.
Smartphones are the opium of the 21st century... And worst of all, they
will become the new identity cards. For example, until recently I could
do transactions with my bank through its website. But now it is
mandatory to have a smartphone and download an application, of course
proprietary.
Anyway, termux and Emacs, without a physical keyboard, is torture. I
usually connect a compact mechanical keyboard that I have for my laptop.
By the way, I've noticed how easy it is to write Elisp functions that
call Termux commands from Emacs. I recently wrote this to send SMS (you
can enter the phone number directly or choose a contact saved in BBDB
data base, if you use BBDB). To see the list of contacts it works better
if you use also some completion framework like ivy or helm:
(defun send-sms ()
(interactive)
(save-window-excursion (bbdb ".+"))
(let* ((tlf (if (yes-or-no-p "Enter a contact: ")
(let ((record (bbdb-get-records "Contact: ")))
(aref
(car (aref (car record) 5)) 1))
(read-from-minibuffer "Phone number: ")))
(sms (read-from-minibuffer "Texto del SMS: "))
(cmd (format "termux-sms-send -n %s %s" tlf sms)))
(call-process-shell-command cmd)))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* An interesting LaTeX package
@ 2021-03-25 9:40 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-25 9:40 UTC (permalink / raw)
To: orgmode
Hi all,
This is not directly related to Org-Mode (apologies for the light
off-topic), but I thought this new LaTeX package uploaded to CTAN could
be of interest to those who regularly export from Org to LaTeX and want
to get a document as 'perfect' as possible, typographically speaking ;-)
The Lua-typo package (according to its description): "tracks common
typographic flaws in LuaLaTeX documents, especially widows, orphans,
hyphenated words split over two pages, consecutive lines ending with
hyphens, paragraphs ending on too short lines, etc."
(https://ctan.org/pkg/lua-typo).
This package can detect any of the following scenarios (taken from the
package documentation):
- paragraph’s last line nearly full?
- paragraph’s last line too short?
- nearly empty page (just a few lines)?
- overfull lines?
- underfull lines?
- widows (top of page)?
- orphans (bottom of page)
- hyphenated word split across two pages?
- too many consecutive hyphens?
- paragraph’s last full line hyphenated?
- short words (1 or 2 chars) at end of line?
- same (part of) word starting two consecutive lines?
- same (part of) word ending two consecutive lines?
It should be noted that the package works only in LuaLaTeX, and that it
highlights flaws only (in draft mode), but does not correct them. It's
similar to another older package, Impnattypo
(https://ctan.org/pkg/impnattypo).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [PATCH] ox.el: add smart quotes for Greek
@ 2021-09-22 19:55 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-22 19:55 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> I believe, the patch is an improvement. It would be nice to have a
> comment clarifying the choice of secondary opening quote mark, but it
> is not required. It seems there is no recommendations or established
> practice for documenting of such decisions. I have not tested the
> patch though.
Since it's a "orthotypographical" addition, where there is a reasonable
doubt in one of the characters, I agree that a minimal explanatory note
in the commit message would be desirable. But it would have (IMHO) to be
something very brief.
>> -`org-export-smart-quotes-alist' and `org-export-dictionary'.
>> +`org-export-smart-quotes-' and `org-export-dictionary'.
>
> It it intentional change? I have not found other variables having the
> same prefix.
Oh, sorry. It's a horrible typo: I modified that part involuntarily, and
I didn't see it :-(.
> That character could get better support in future. I know, such chance
> is almost improbable, but imagine, a person familiar with the paper of
> Haralambous would consider change of the quote mark in question
> believing that Org developers were not aware of the "right" symbol. A
> comment in the source code may provide a hint that the choice was conscious.
>
> I forgot to mention it in my message from 2020-08-15 that I did not
> find the U+201F character in TeX pre-unicode LG* encodings for Greek.
In fact, the character is only problematic in pdfTeX. In XeTeX and
LuaTeX there is no problem, and you can also use the csquotes package.
But in pdfTeX you can't even get it with the
\usepackage[utf8x]{inputenc} option, which is to be expected, since
Unicode support of imputenc is very limited. LuaTeX is the natural
replacement for pdfTeX, but at the moment we have to maintain backward
compatibility and I can't find a way to represent that character in
pdfTeX. This second level quotes issue is not mentioned by Apostolos
Syropoulos in the babel greek documentation:
(https://www.ctan.org/pkg/babel-greek). There is probably no support for
this character in babel-greek.
Before uploading a corrected version of the patch (with a small
explanatory note), I could consult Haralambous himself by mail, and ask
him what he thinks of this question...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* [PATCH] org-manual.org: update and add info for arbitrary :float values
@ 2022-02-11 20:37 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-11 20:37 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
Hi all,
From the commit:
e0bc2b37f :: lisp/ox-latex.el: Allow arbitrary float environments
The `t' option for `:float' in tables and images is no longer valid.
That is, something like
#+ATTR_LaTeX: :float t
[[file:foo.jpg]]
would create in LaTeX export:
\begin{t}
\centering
\includegraphics[width=.9\linewidth]{foo.jpg}
\end{t}
I am attaching a patch to update those changes to the Manual.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-doc-org-manual.org-add-arbitrary-float-values.patch --]
[-- Type: text/x-patch, Size: 1932 bytes --]
From 03aacd306355741f67533325dd6dbd8c5a472ec0 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 11 Feb 2022 21:18:16 +0100
Subject: [PATCH] doc/org-manual.org: add arbitrary :float values
* Tables in LaTeX export: remove `t' value
* Images in LaTeX export: remove `t' value
---
doc/org-manual.org | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index b8c61fddd..4c6fcf8db 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13572,7 +13572,11 @@ include:
The table environments by default are not floats in LaTeX. To make
them floating objects use =:float= with one of the following
- options: =sideways=, =multicolumn=, =t=, and =nil=.
+ options: =sideways= (for a =sidewaystable= environment),
+ =multicolumn= (to span the table across multiple columns of a page
+ in a =table*= environment) and =nil=. In addition to these three
+ values, =:float= can pass through any arbitrary value, for example a
+ user-defined float type with the =float= LaTeX package.
LaTeX floats can also have additional layout =:placement=
attributes. These are the usual =[h t b p ! H]= permissions
@@ -13684,11 +13688,6 @@ export back-end wraps the picture in a floating =figure= environment.
To float an image without specifying a caption, set the =:float=
attribute to one of the following:
-- =t= ::
-
- For a standard =figure= environment; used by default whenever an
- image has a caption.
-
- =multicolumn= ::
To span the image across multiple columns of a page; the back-end
@@ -13708,6 +13707,11 @@ attribute to one of the following:
To avoid a =:float= even if using a caption.
+- Any arbitrary value ::
+
+ For example, a user-defined float type with the =float= LaTeX package.
+
+
Use the =placement= attribute to modify a floating environment's
placement.
--
2.35.0
^ permalink raw reply related [relevance 8%]
* Re: Smart quotes for Greek (questions for a possible patch)
@ 2021-08-16 13:57 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-16 13:57 UTC (permalink / raw)
To: mvar; +Cc: public, orgmode
Hi Michalis. Thank you for your comments.
mvar writes:
> i can confirm the «» characters are the proper ones for the first level
> of quoting..Now about second level, personally i haven't seen such nesting in
> ages but IIRC they should be the ones (or *very* similar) in the linked image you posted ->
> \textquotedblleft and \textquotedblright. I've no idea how these
> translate to UTF. Note that the standard greek keyboards & keymaps do not have
> any of these characters mapped by default (not even «» ), most people use the standard
> english double/single quotes, at least in electronic writing (articles,
> daily communication etc).
> Protesilaos (cc) might have a better view on this matter.
Yes, I think \textquotedblleft and \textquotedblright could be a good
solution. Those are the first level quotes for English and other
languages, and the second level quotes for Spanish, so in this case the
Spanish settings in `org-export-smart-quotes-alist' could be copied for
Greek. In Unicode they are equivalent to
“ LEFT DOUBLE QUOTATION MARK U+201C
and
” RIGHT DOUBLE QUOTATION MARK U+201D
In fact, the second quotes, U+201D, would be the correct ones for Greek
(always, according to Haralambous). The only difference is for the
opening quotes: in this case Greek would use (again, according to
Haralambous) the character U+201F: ‟ (DOUBLE HIGH-REVERSED-9 QUOTATION
MARK), which is like the U+201C char, but upside down. In LuaTeX and
XeTeX (and in HTML) there is no problem to represent that character,
because these two TeX engines are based on Unicode. The problem would be
the backward compatibility with pdfTeX. I haven't managed to get this
character in pdfTeX using inputenc with the utf8 option.
Therefore, we could leave for the second-level quotation marks the
tandem U+201C/201D, as the lesser evil. Let's see what Protesilaos
thinks.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: caption width in LateX export
@ 2021-12-27 13:28 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-27 13:28 UTC (permalink / raw)
To: Sebastian P. Luque; +Cc: orgmode
Sebastian P. Luque writes:
> Thank you, Juan. Unfortunately, there is a price for this solution as
> it is now impossible to name and refer to this segment as usual:
I see. Have you tried the option with LuaTeX that I put in my other
message? You can compile with LuaTeX also using latexmk:
(setq org-latex-pdf-process
'("latexmk -lualatex -e '$lualatex=q/lualatex %%O -shell-escape %%S/' %f"))
In any case, since this is a simple substitution, you can use also a
function in Elisp as a final output filter[1]:
#+BIND: org-export-filter-final-output-functions (caption-auto-width)
#+begin_src emacs-lisp :exports results :results none
(defun caption-auto-width (text backend info)
(when (org-export-derived-backend-p backend 'latex)
(with-temp-buffer
(insert text)
(save-excursion
(goto-char (point-min))
(while (re-search-forward "\\(\\\\includegraphics.+\\)" nil t)
(replace-match "\\\\sbox0{\\1}" t nil)))
(save-excursion
(goto-char (point-min))
(while (re-search-forward "\\(\\\\caption.+\\)" nil t)
(replace-match "\\\\begin{minipage}{\\\\wd0}\\\\usebox0\\1\\\\end{minipage}" t nil)))
(setq text (buffer-string)))))
#+end_src
Vid. [[fig:1]]
#+NAME: fig:1
#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus
#+ATTR_LaTeX: :width .3\linewidth
[[my-image.jpg]]
[1] You need to set this variable as non-nil, in order to use bind
keywords: (setq org-export-allow-bind-keywords t)
Hope this works,
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
@ 2023-09-06 22:20 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-06 22:20 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> I consider the following as an issue rather close to the discussion in
> the thread
> Juan Manuel Macías. Fallback fonts in LaTeX export for non latin
> scripts. Wed, 30 Aug 2023 08:25:53 +0000.
> https://list.orgmode.org/878r9t7x7y.fsf@posteo.net
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042450
> elpa-org: #+LANGUAGE: de-de is not working in LaTeX export. Debian Bug
> report logs
>
> I am unsure if the change was intentional.
I seem to remember that when I made org-latex-language-alist I made some
corrections to a few language codes. I was guided by page 19 of the
Babel manual and by
https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
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:
[identification]
charset = utf8
version = 1.3
date = 2020-06-30
name.local = Deutsch
name.english = German
name.babel = german
name.polyglossia = german
tag.bcp47 = de
language.tag.bcp47 = de
tag.bcp47.likely = de-Latn-DE
tag.opentype = DEU
script.name = Latin
script.tag.bcp47 = Latn
script.tag.opentype = latn
level = 1
encodings = T1 OT1 LY1
derivate = no
and babel-de-AT.ini:
[identification]
charset = utf8
version = 1.3
date = 2020-06-30
name.local = Deutsch
name.english = German
name.babel = austrian german-austria german-at
name.polyglossia = german
tag.bcp47 = de-AT
language.tag.bcp47 = de
tag.opentype = DEU
region.local = Österreich
region.english = Austria
region.tag.bcp47 = AT
script.name = Latin
script.tag.bcp47 = Latn
script.tag.opentype = latn
polyglossia.variant = austrian
polyglossia.spelling = new
level = 1
encodings = T1 OT1 LY1
derivate = no
ini files use german and german-at, but in classic babel nomenclature
(ldf files) we have ngerman and naustrian.
Maybe it should be corrected like this:
("de-de" :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
("de" :babel-ini-only "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
The case of de-at is more problematic because a single language code
serves for naustrian (ldf) and (ini:) austrian, german-at and
german-austria. Some new property, something like :babel-ini-alt, would
have to be introduced . There are other similar cases on the list, such
as el-polyton, which points to polutonikogreek (ldf). In general, except
in cases where only the ini file exists, I used the ldf nomenclature for
backward compatibility.
In any case, these dances of language names between some places and
others make the list of language names that Ihor is working on
increasingly necessary.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 8%]
* Improvements in the default LaTeX preamble (was: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists)
@ 2022-07-23 17:15 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-23 17:15 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> My vote is to configure babel by default if it is possible to provide
> default preamble that allows reasonable quality of PDF for simple Org
> documents with no explicit configuration.
>
> Ideally, the following should be possible out of the box. When no
> advanced features are involved, user should be able to just export
> document to e.g. having printed version of their notes during a
> meeting, to send a summary to the boss. etc. It should be possible for
> users completely ignorant in respect to LaTeX.
>
> Likely language is not enough and e.g. paper size should be guessed
> (LC_PAPER?) as well.
>
> If a document require careful tuning then a couple of extra lines in
> the org file or a couple of additional custom variables in the init
> file should not be a problem.
I think that my position, after all these discussions here and in other
threads, needs a couple of clarifications:
- I am in favor of Org producing a consistent "standard" preamble for
LaTeX out-of-the-box, so that users get a technically optimal PDF
without messing with LaTeX code. This would include not only issues
related to document languages (babel and polyglossia) but also fonts
(especially XelaTeX and LuaLaTeX support), page layout (with geometry
package), publishing support and some other things that can be
proposed here. In this regard, I have changed the subject of this
thread, if that's okay with you.
- I can agree that all of the above is by default. But it seems
essential to me that there is at least the possibility of giving all
that a nil value at a global level, for users who need more control
and want to write (La)TeX code or want to load the entire preamble
from an external document (a .tex file or a .sty file) . Which is not
incompatible with document-level control and fine-tuning (*only* if
the above is enabled).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* [TIP] Export to LaTeX and HTML with a watermark
@ 2020-12-23 2:11 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-23 2:11 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]
Hi,
Recently, I needed to export a document to both LaTeX and HTML with a
watermark background. I came to write this little function (for LaTeX,
the 'draftwatermark' package is used; for html, a bit of CSS. The
optional arg `text' is the text of the watermark; by default what is
printed is "DRAFT"):
#+begin_src org
,#+begin_src emacs-lisp :exports results :results none
(defun my-watermark (&optional text)
(cond ((org-export-derived-backend-p org-export-current-backend 'latex)
(concat "#+LaTeX_Header:\\usepackage"
(if text
(format "[text=%s]" (replace-regexp-in-string " " "~" text))
"")
"{draftwatermark}"))
((org-export-derived-backend-p org-export-current-backend 'html)
(concat "@@html:<p id=\"watermark\">"
(if text
(format "%s" text)
"DRAFT")
"</p>@@"))))
,#+end_src
#+end_src
The CSS could be (source:
https://stackoverflow.com/questions/68569/text-watermark-on-website-how-to-do-it):
#+begin_src org
,#+html_HEAD: <style>#watermark {color: #d0d0d0; font-size: 200pt; -webkit-transform: rotate(-45deg); -moz-transform: rotate(-45deg); position: absolute; width: 100%; height: 100%; margin: 0; z-index: -1; left:-100px; top:-200px;}</style>
#+end_src
And then, this replacement macro:
#+begin_src org
,#+MACRO: wmark (eval (if (org-string-nw-p $1)(my-watermark $1)(my-watermark)))
#+end_src
And finally, an example:
#+begin_src org
{{{wmark(Top secret!)}}}
Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
accumsan nisl.
(...)
#+end_src
Regards,
Juan Manuel
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply [relevance 8%]
* Re: A simple Lua filter for Pandoc
@ 2022-01-07 15:14 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-07 15:14 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> Form my point of view it is not worse than "\slash{}" entities.
Yes, I also use macros a lot, especially for more complex constructions.
Macros, entities and other tricks have their pros and cons, but they
allow me to have a certain group of characters under control.
>> https://i.imgur.com/f6X7qLs.png
>
> In this example there is no need to replace "<" by entity since it can
> not be confused with <http://te.st/> links.
As I have already said, this comes from a desire to keep a series of
characters under control, because they can be confused with the Org
marks or because I can get confused when working with the text,
especially if it is an imported text. In the case of "<" and ">", many
authors usually use them for various contexts in philology (instead of
the correct characters for some of those contexts, such as
RIGHT-POINTING ANGLE BRACKET and LEFT-POINTING ANGLE BRACKET: in that
case, I have to replace with the correct symbol). In general, I am
calmer if I have, in one way or another, all those symbols conveniently
"delimited", because even if Org is not wrong, I can get confused.
Anyway, regardless of the idiosyncrasy of my workflow, the origin of
this thread (the function in Lua) was in case someone wants to adapt it
to their own workflow, and needs to substitute some strings for others
when importing from docx or odt.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Org for developing LaTeX packages
@ 2022-07-16 14:33 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-16 14:33 UTC (permalink / raw)
To: orgmode; +Cc: Marcin Borkowski
Hi all,
I am writing a package for LuaLaTeX and have decided to use Org for it.
The reasons: org is more powerful, more versatile and more cool than the
'official' LaTeX literate programming utility, docstrip.
Searching for information on this list I found this post from Marcin
Borkowski, from 2013, where he comments on very interesting things
regarding these topic:
https://list.orgmode.org/20130311230246.4c629e36@aga-netbook/
Out of curiosity, I wonder if Marcin or someone else finally got around
to implementing something concrete for this. I think some kind of
extension to org-babel-tangle that would generate the typical docstrip
.dtx and .ins files might be nice. Perhaps this would open up the use of
Org to LaTeX package developers, though admittedly docstrip is deeply
rooted in planet LaTeX and hardly anything else is used.
When I release my package I'll write a makefile, in the style of the
wallcalendar package, which is also written in Org:
https://github.com/profound-labs/wallcalendar/blob/master/Makefile
BTW, Wallcalendar is the only LaTeX package I know of (besides mine,
still work in progress) that is written in Org and not in docstrip. I
don't know if there are any more...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [Question] Custom parse tree filter
@ 2021-05-17 12:20 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-17 12:20 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hi Nicolas,
Thank you very much for your excelent explanation, which has helped me
to learn new and valuable things.
I chose `headline' instead of `section' because in the scenario where I
want to apply those LaTeX groups I was looking for something like this:
{level 1 - group 1
{level 2 group 1 + group 2
{level 3 group 1 + group 2 + group 3
{etc. }}}}
I have tested your function and it works fine when all headers are at
the same level, but with different levels the filter understands both
properties as `font' (?). Anyway, and only for practical purposes, and
because I think that my initial idea of 2 properties was uneconomical, I
have slightly modified your function with a single property
`:fontspec:'. Now, with a couple of marks and some regexp both the
\fontspec group and the one with \addfontfeature are extracted:
| :fontspec: font ! optional: features | \fontspec{font}[features] |
|----------------------------------------+---------------------------|
| :fontspec: > features | \addfontfeature{features} |
then the variable `fontspec':
(let* ((font <font-string-obtained-via-regexp>)
(fontfeature <fontfeature-string-obtained-via-regexp>)
(fontspec (cond (font font) (fontfeature fontfeature))))
is passed as an argument of `(funcall create-export-snippet ...)'
With a single property it works fine, although I have to test more...
Thak you very much!
Best regards,
Juan Manuel
Nicolas Goaziou writes:
> Hello,
>
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> I am writing a custom parse tree filter that does the following (LaTeX
>> backend): if a heading has the ':font:' property, the content of that
>> heading is enclosed in a LaTeX group. If the property is ':fontfeature:',
>> then the content is enclosed in a different group. The filter works fine
>> when all the headings are at the same level. But with different levels,
>> it does not returns the expected result. It's evident that I'm doing
>> something catastrophically wrong :-). I wonder if anyone could put me on
>> the track of the origin of my error...
>>
>> Below, the offender function and a sample. Thanks in advance!
>
> I think you are operating at the wrong level. Higher level headlines
> contain lower level ones. I suggest to operate on sections instead.
>
> Also, using `org-element-interpret-data' is meh because you're operating
> at the parse tree level. You can insert export-snippet objects directly.
>
> Here's a proposal. This could be refactored, but you get the idea.
>
> (defun my-custom-filters/fontspec-headline (tree backend info)
> (when (org-export-derived-backend-p backend 'latex)
> (org-element-map tree 'section
> (lambda (section)
> (let ((font (org-export-get-node-property :FONT section t))
> (fontfeature (org-export-get-node-property :FONTFEATURE section t))
> (create-export-snippet
> ;; Create "latex" export-snippet with value V.
> (lambda (v)
> (org-element-create 'export-snippet (list :back-end "latex" :value v)))))
> (cond
> (font
> (apply #'org-element-set-contents
> section
> (append (list (funcall create-export-snippet "%font start\n"))
> (org-element-contents section)
> (list (funcall create-export-snippet "%font end\n")))))
> (fontfeature
> (apply #'org-element-set-contents
> section
> (append (list (funcall create-export-snippet "%fontfeature start\n"))
> (org-element-contents section)
> (list (funcall create-export-snippet "%fontfeature end\n"))))))))
> info)
> tree))
>
> Also, when "org-cite-wip" is merged, you will be able to replace, e.g.,
>
> (funcall create-export-snippet "%fontfeature start\n")
>
> with
>
> (org-export-raw-string "%fontfeature start\n")
>
> Regards,
^ permalink raw reply [relevance 8%]
* Re: convert subtree or nested list to table
[not found] ` <CAN_Dec8iqKS+3qvjkYvQxovegnEzqR_rra0Q-ZA9baPz1mXDAA@mail.gmail.com>
@ 2021-07-06 12:56 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-06 12:56 UTC (permalink / raw)
To: Matt Price; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]
Hi Matt, sorry for the slow reply...
Matt Price writes:
> I'd love to try that, thanks. I think it would be really helpful.
> Much appreciated!
Some previous caveats:
- *The code is very raw*. I wrote it almost as a "proof of concept" for
my personal use, therefore it is quite improvable. In any case, it
works (but i don't know if it will help you get what you want...).
- The attached example is optimized to export to LaTeX. Use the tabularx
environment, which is ideal for tables with a lot of textual content.
- As for the code, there are two basic functions:
`my-org/edit-table-cell' and
`my-org/kill-edit-table-cell-buffer-and-save'. To edit an empty cell,
you have to write something in that cell first.
- The basic idea is that within each cell, the content is a single line
(unfilled). In the edit buffer, the content is filled. There are two
macros to indicate a line break and a paragraph end: {{{nl}}} and
{{{par}}}. In the edit buffer you can put line breaks and white lines,
but all of that is lost inside the cell once saved (all is a single
line), so those macros are needed to indicate line or paragraph breaks
(in LaTeX).
Best regards,
Juan Manuel
[-- Attachment #2: test-tables.org --]
[-- Type: application/vnd.lotus-organizer, Size: 20363 bytes --]
^ permalink raw reply [relevance 8%]
* Re: Export LaTeX command inside figure environment
@ 2022-05-08 16:12 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-08 16:12 UTC (permalink / raw)
To: Thomas S. Dye; +Cc: Maxim Nikulin, orgmode
Thomas S. Dye writes:
> It would be better to have a LaTeX attribute, say :commands, that
> places commands within \begin{figure} ... \end{figure}.
This is a possible solution from the LaTeX side, which would avoid
having to modify the Org code and can also be used to introduce more
complex arbitrary code into the figure environment. It consists of
defining a variable (for arbitrary code) and redefining the figure
environment to include that variable. Something like this:
#+NAME: preamble
#+begin_src latex :exports none
\usepackage{graphicx,xparse}
\def\myfigcode#1{#1}
\let\svfigure\figure
\let\endsvfigure\endfigure
\DeclareDocumentEnvironment{figure}{o}{%
\IfNoValueTF{#1}{%
\begin{svfigure}}
{\begin{svfigure}[#1]}
\myfigcode%
}
{\end{svfigure}}
#+end_src
#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <<preamble>>
#+end_src
Here I use the dummy images from the graphicx package. Of course, then
it is necessary to apply a zero value to the variable again, or enclose
all in a \begingroup...\endgroup. It's a bit tricky and I haven't tried
it too much:
@@latex:\begingroup\def\myfigcode{{\centering\fbox{\textbf{Hello world!!!}}\par\vspace{5ex}}}@@
#+caption: This is a caption
#+ATTR_LaTeX: :placement [h] :width .5\linewidth
[[file:example-image-a.jpg]]
@@latex:\endgroup@@
#+caption: This is a caption
#+ATTR_LaTeX: :placement [h] :width .5\linewidth
[[file:example-image-b.jpg]]
A screenshot:
https://i.imgur.com/8JIU6nX.png
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: simple request letter - help
@ 2022-05-13 18:22 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-13 18:22 UTC (permalink / raw)
To: andrés ramírez; +Cc: orgmode
hi Andrés,
andrés ramírez writes:
> Hi. Juan.
> My comments below.
I'll explain what happens. There really isn't an alignment issue. TeX by
default applies a first line indent to paragraphs. It also defaults to
applying English typographical conventions, as is the case in your
document, where the first paragraph following a section is not indented.
This is what is happening :):
section
no indent -------------
indent ----------
indent ----------
Another more general typographical convention is that when paragraphs
are separated by a vertical space, they do not need to indent the first
line, as it is a redundant mark. Besides, you are making paragraph
separation by direct format (\bigskip). I usually recommend not applying
direct format in LaTeX, or applying it as little as possible. To disable
the first line indentation and make the paragraphs have a space between
them, it is enough that you add this:
#+LaTeX_Header: \parindent=0em\parskip=\bigskipamount
That way, you're giving the first line indentation a global value of
zero and a paragraph spacing value equivalent to \bigskip, and you don't
need to put a \bigsip every time you start a paragraph.
On the other hand, this code at the end does not give you an error?
\makebox[1.5in]{\hrulefill} \hspace {1.0in} \\
& John Doe \\
& ID: XXXXXXXX\\
best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [off-topic] E-readers and Org-Mode
@ 2022-10-31 12:18 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-31 12:18 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> P.S. Concerning free PDF annotation tool, I have not tested if it is
> convenient and available on Android, but Firefox-106 release notes
> have the following entry:
>
>> It is now possible to edit PDFs: including writing text, drawing,
> and adding signatures.
>
> Almost certainly "edit" in their parlance in namely annotations, not
> real changes of PDF structure.
Interesting, I'll take a look at it. I haven't used firefox as my
default browser in a while. On desktop and laptop I use a combination of
Eww and Qutebrowser, which is more keyboard oriented. I have Firefox
almost relegated to negotiations with the Spanish government, such as
taxes and little else. On mobile I use Brave browser. And lately I've
noticed that it's not as hard as I thought to navigate with Eww-mode in
Termux/Emacs by touch! :-)
BTW, I have found another free app to annotate PDF on Android, KOReader:
https://f-droid.org/en/packages/org.koreader.launcher.fdroid/ It is
mainly intended for e-ink screen e-readers. It's under active
development as well (https://github.com/koreader), and even offers
builds and tutorials for installing it on specific non-Android devices
(Kobo, reMarkable, etc.).
I have tried to make some annotations on a PDF to open it later on the
desktop pc. Annotations are correctly read by pdf-tools, Atril, Evince,
Okular, etc. And they are also exported correctly to Org via the
org-noter function org-noter-create-skeleton, which I didn't know about
and is tremendously useful.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [PATCH] ox.el: add smart quotes for Greek
@ 2021-09-23 17:17 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-23 17:17 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Hi Maxim,
Max Nikulin writes:
> Juan Manuel, I feel some misunderstanding. I am not asking for more
> arguments in support of current variant of patch. CLDR entry, EU
> recommendations, the mail from Protesilaos, absence of named HTML
> entity, complications with pdfTeX are more than enough.
I completely agree with what you say, but I think I have explained wrong
in my previous mail. I said about consulting YH because his article is
something old (90s), and his current opinion on "the state of the
question" could help me compose my little explanatory note. And in any
case, I think everyone here agrees that the character that he proposed
in his paper is unfeasible in Org, for all the reasons you have
summarized. On the other hand, the orthographic norms are not sacred
norms; rather, they are determined by use and customs. For example, here
in Spain the manuals and treatises tend to disagree on certain issues.
In my opinion, many times it is better to talk about trends more than
norms[1], and trends that more or less end imposing, almost by mere
natural selection (another matter is that sometimes bad habits are also
imposed, for using inappropriate software, but this is not the case
where we are).
[1] For example, in Spanish of Spain, the quotation marks are «“ ”»,
But in Mexican Spanish they use “‘’” as in English. In fact the
csquotes LaTeX package includes both styles.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [tip] org-publish to work with (very) large books
@ 2022-05-26 13:48 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-26 13:48 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Christian Moe, orgmode
Hi Ihor and Christian,
Ihor Radchenko writes:
> Christian Moe <mail@christianmoe.com> writes:
>
>> Do I understand correctly that the main advantage of this approach (over
>> #+INCLUDE) is the ability to continuously update preview of the whole
>> book with latexmk -pvc even if you only re-export one chapter from
>> Org-mode?
>
> I am not sure why Juan did not use include. Include would not require
> LaTeX to re-compile unchanged files. See
> https://tex.stackexchange.com/questions/246/when-should-i-use-input-vs-include
>
>> I couldn't find the :body-only publishing option in the docs ...?
>
> See [[info:org#The Export Dispatcher][org#The Export Dispatcher]]
>
> Best,
> Ihor
>
Sorry for not explaining the \input part in more detail. I think the
essential part here is that all the .tex files (the subdocuments) are
already created by org-publish before I compile the master document. The
master document simply stores all the subdocuments: I use
\input{subdocument.tex} instead of the org #+INCLUDE directive (not the
LaTeX \include command). The master document calls ready-made TeX files,
not Org files. And it is independent of the whole org-publish process,
which is responsible for creating only the parts of the book. This
procedure, apart from being able to compile parts of the book in real
time with latexmk -pvc, allows me to have more control over these parts.
But it makes more sense to use it when dealing with very long books. The
first time I used it was in a book of more than 1000 pages :-)
The skeleton of the process is that subdocuments are produced with
org-publish (as uncompiled tex files) and the master document is
exported to tex from org and then compiled with latexmk inside /tex
directory.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [tip/offtopic] A function to describe the characters of a word at point
@ 2022-07-15 0:56 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-15 0:56 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: Samuel Wales, orgmode
Hi, Marcin and Samuel, thanks for your comments,
Marcin Borkowski writes:
> You might want to extend it and create a minor mode which would display
> data about the current character in the echo area, Eldoc-style, or in
> a tooltip when you hover the mouse pointer over a character. Depending
> on what exactly you need, these ideas might be more or less useful, of
> course.
I also have written a smaller function to display a quick information of
a single character at point, something much simpler and not as verbose
as describe-char. But it had never occurred to me to do something
eldoc-like with it. In my case, although for those contexts I prefer
quick information (describe-char also has its relaxing moment), I don't
feel such an urgency :-).
In any case, something quick and dirty, just as a proof of concept,
could be this:
(define-minor-mode char-info-at-point-mode
"TODO"
:init-value nil
:lighter ("chinfo")
(if char-info-at-point-mode
(add-hook 'post-command-hook #'char-name-at-point nil t)
(remove-hook 'post-command-hook #'char-name-at-point 'local)))
(defun char-name-at-point ()
(interactive)
(let* ((char-name (get-char-code-property (char-after (point)) 'name))
(code (format "#%x" (char-after (point))))
(dec (get-char-code-property (char-after (point)) 'decomposition))
(info (concat
char-name
" / "
code
" / descomp: "
dec
"\s"
(mapconcat (lambda (cod)
(format "#%x" cod))
dec "\s+\s"))))
(message info)))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* A function to perform Org related searches in several places
@ 2022-10-05 9:49 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-05 9:49 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
Hi all,
For my personal use I have written a function which performs Org related
searches in different places. The list of places is expandable, but so
far I found them useful: this mailing list, the Org Manual (via org-ql),
the Git log and the Org Reddit. The idea was that everything would be
done without leaving Emacs confort, so the results from the internet are
returned in EWW.
Before entering the search term, it defaults to the word at point or the
marked region.
The function has two versions. The first version does not depend on any
external packages to display the options. The second version includes a
simple hydra. The hydra version has the advantage that you can have the
hydra buffer open and continue running more searches on the same term. I
don’t know if it’s very orthodox to include the definition of the hydra
inside the function (I would say no, I don’t know), but I couldn’t think
of another way to pass the argument to the different heads of the hydra…
It’s homemade and improvable code, but I’m attaching it here in an Org
document, in case someone finds it useful :-).
Best regards,
Juan Manuel
[-- Attachment #2: function.org --]
[-- Type: application/vnd.lotus-organizer, Size: 2915 bytes --]
^ permalink raw reply [relevance 8%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
@ 2024-01-16 19:33 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-16 19:33 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> The very reason we use \\[0pt] is because it supposed to prevent
> interpreting [...] at the new line/transcoded element as argument.
>
> You demonstrated that it is yet not always safe enough.
>
> May it be better to use something like
>
> \newcommand\nothing{}
> \newcommand{\safenewline}{\\\nothing}
>
> And then use \safenewline instead of \\[0pt]
>
> In my tests,
>
> \begin{center}
> \begin{tabular}{ll}
> [t] & s\safenewline
> [I] & A\safenewline
> [m] & kg\safenewline
> \end{tabular}
> \end{center}
>
> Does not suffer from misinterpreting new line as argument.
I remember the thread where these issues were discussed and the long
discussion where many alternatives were proposed. After all, the \\[0pt]
solution still seems the safest to me. It seems that the problem is
located only in the verse environment, probably due to some particular
redefinition of the \\ macro that makes that environment.
In any case, square brackets are a problematic character in LaTeX
(think, e.g., of some environment that takes an optional argument). I
think pandoc chooses to always export them as {[}{]}:
#+begin_src sh :results latex
str="[hello world] [foo] [bar]"
pandoc -f org -t latex <<< $str
#+end_src
#+RESULTS:
#+begin_export latex
{[}hello world{]} {[}foo{]} {[}bar{]}
#+end_export
We could do the same, but I'm afraid it's too late if
org-latex-line-break-safe already exists... I don't remember if
something similar was proposed in that discussion, and it was rejected
for some reason.
> `org-latex-verse-block' already has a giant regexp replacement:
>
> ;; In a verse environment, add a line break to each newline
> ;; character and change each white space at beginning of a line
> ;; into a normal space, calculated with `\fontdimen2\font'. One
> ;; or more blank lines between lines are exported as a single
> ;; blank line. If the `:lines' attribute is used, the last
> ;; verse of each stanza ends with the string `\\!', according to
> ;; the syntax of the `verse' package. The separation between
> ;; stanzas can be controlled with the length `\stanzaskip', of
> ;; the aforementioned package. If the `:literal' attribute is
> ;; used, all blank lines are preserved and exported as
> ;; `\vspace*{\baselineskip}', including the blank lines before
> ;; or after CONTENTS.
>
> We may as well strip the trailing \\[0pt] there.
I think it would be best to remove the last \\[0pt] in the verse block.
I can prepare a patch, but I'm afraid that org-latex-verse-block is
becoming an homage to replace-regexp-in-string...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
@ 2024-01-20 20:27 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-20 20:27 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Max Nikulin
Ihor Radchenko writes:
> I see your point.
> Although I am still a bit hesitant to remove
> `org-latex-line-break-safe'.
> What would be the benefit of removing it? For now, I mostly just see
> that it will make the life harder for users in Scenario B.
It's a complicated situation, because we now have two solutions to the
same problem... It certainly sounds a bit abrupt to remove
org-latex-line-break-safe (at least for now). I see no problem in both
solutions coexisting. After all, the user can always give an "\\\\"
value to org-latex-line-break-safe. The other possibility is that
org-latex-line-break-safe is selectively deleted, as you mentioned in a
previous email. In tables and verse blocks, unless I'm missing
something, I think adding [0pt] would be unnecessary, with the new
solution.
> For verse blocks, AFAIU, even \\ is problematic. (Correct me if I am wrong)
From the tests I have done, the problem of the vertical space being
altered after the verse environment only appears when the last line ends
in \\[0pt]. If it ends in \\ the problem does not appear. It is not
recommended that a verse environment ends in \\, but it does not seem to
influence the output. In fact, that was how it was in Org in the days
pre org-latex-line-break-safe and there were never any problems.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Footnote tooltips (an attempt)
[not found] ` <CAJcAo8tsK5o+789Wv=i6ddiSrM4fDyX8HCvjAgDLXGyLXWRWmQ@mail.gmail.com>
@ 2022-02-23 19:52 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-23 19:52 UTC (permalink / raw)
To: Samuel Wales, Ypo; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]
Hi Samuel,
Samuel Wales writes:
> what a great idea. i am interested in your comments. emacs has lots
> of tooltip-related features. eldoc, help-at-pt, mouse-avoidance, etc.
> you don't want tooltips when your mouse happens to end up over. or
> for your mouse to go haywire just because you ended up over. i ran
> into a lot of confusion with various mechanisms.
>
> [e.g. i like having tooltips in echo area, and don't like eldoc for
> function sigs, and do want cursor/mouse consistency.]
>
> i found that some tooltip features actually break others. just
> wondering if you noticed this and what you think of it.
I don't have much experience with Emacs tooltips and I haven't studied
them much, because I hardly use the mouse in Emacs :-) But I noticed
that you can also display the content of a tooltip in the echo area,
with `<C-h .>' (`display-local-help'), or even set to non-nil
`help-at-pt-display-when-idle' and evaluate `help-at-pt-set-timer', so
that a tootltip is displayed at point; and in this scenario, they can be
useful to me to quickly have some type of information.
You can also set this variable to force tooltips always in the echo
area:
(setq tooltip-use-echo-area t)
Anyway, I haven't given up on the idea of footnote tooltips yet. Here's
a new version of the code I attached in my first post in this thread,
and I think it's simpler now and works better, though I don't know if it
might have any side effects... Footnote tooltips are activated with the
minor mode `my-org-fn-tooltip-mode'.
A new demo video:
https://cloud.disroot.org/s/sBGJjCzbYgYbn5k
Best regards,
Juan Manuel
[-- Attachment #2: fn-tooltips.org --]
[-- Type: application/vnd.lotus-organizer, Size: 3004 bytes --]
^ permalink raw reply [relevance 9%]
* Re: emphasizing source code words
@ 2021-02-04 12:13 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-04 12:13 UTC (permalink / raw)
To: Luca Ferrari; +Cc: orgmode
Hi Luca
Luca Ferrari <fluca1978@gmail.com> writes:
> Thanks, but stil Im not able to figure it out. I've searched thru the
> org documentation without any luck.
>
> Luca
To use the minted package as backend (https://www.ctan.org/pkg/minted),
I have in my Emacs:
(setq org-latex-listings 'minted)
(setq org-latex-minted-options
'(("frame" "lines") ("linenos=true") ("breaklines")))
You also need to install the Python pigments library on your OS. In
Arch (in my case) is the python-pygments package.
And you have to make sure that when you export to LaTeX it always compiles
with the -shell-escape option. For example:
(setq org-latex-pdf-process
'("lualatex -shell-escape -interaction nonstopmode -output-directory %o %f"
"lualatex -shell-escape -interaction nonstopmode -output-directory %o %f"
"lualatex -shell-escape -interaction nonstopmode -output-directory %o %f"))
Lastly, in Org docs you need of course to load the minted package:
#+LaTeX_HEADER: \usepackage{minted}
You can see how the highlighting looks like in this post from my blog (in
Spanish): under the title there is a button to download the entry in PDF
version: https://lunotipia.juanmanuelmacias.com/evitar_funcion_lua.html
Finally, you may be interested in this new package that TEC has written:
https://www.reddit.com/r/emacs/comments/lbkmmz/the_best_syntax_highlighting_in_a_pdf_youll_see_a/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: idea for capture anywhere in x
@ 2022-10-11 9:11 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-11 9:11 UTC (permalink / raw)
To: Jean Louis; +Cc: emacs-orgmode
Jean Louis writes:
> Did you try to invoke Emacs without having Emacs in front of you? Once
> you try, come back and tell me how would you capture anything from X
> selection into Emacs without having Emacs window in front of you.
>
> I do not know how. My thinking stops right there.
>
> I have four workspaces, Emacs is not on each of them.
>
> How do I invoke Emacs without having it in front of me with just 1 key
> binding?
One solution is to let Emacs be your X window manager. I'm not saying
it's "the solution" to what's being discussed in this thread (sorry for
the noise), but in my case it is. With EXWM I don't need, for example,
anything like org-protocol. Even if I want to copy/cut/paste something
inside X, I have these three simultation keys defined in EXWM:
([?\C-y] . [?\C-v])
([?\C-w] . [?\C-x])
([?\M-w] . [?\C-c])
and I can use C-y, C-w or M-w in LibreOffice, Gimp or wherever.
One more example. If I'm in the external browser I normally use when I'm
not using eww (qutebrowser), I have a simple Org-capture template to
copy a url and create an Org heading with the link. I just hit yy on
qutebrowser and, without leaving there, call org-capture (C-c c). I have
another template to download images with org-download; another to create
a heading with the information extracted from google-scholar, etc. I
mean that using EXWM these problems don't exist, because, one way or
another, you're always in Emacs.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Dired images in an Org buffer
@ 2021-11-23 16:52 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-23 16:52 UTC (permalink / raw)
To: orgmode
Hi,
I don't like image-dired thumbnails, so I wrote this function to preview all
images in a directory in an Org buffer. I share it here, in case it is
useful to someone:
#+begin_src emacs-lisp
(defun my-org-img-dired-preview ()
(interactive)
(if (not (derived-mode-p 'dired-mode))
(error "not in dired")
(let* ((dir-name default-directory)
(buf (concat "*" dir-name "--images *")))
(setq my-img-dired-list nil)
(save-excursion
(goto-char (point-min))
(while (re-search-forward "\\.png\\|\\.jpg\\|\\.tif" nil t)
(let* ((img-path (dired-get-filename)))
(add-to-list 'my-img-dired-list img-path t))))
(when (get-buffer buf)
(kill-buffer buf))
(get-buffer-create buf)
(set-buffer buf)
(org-mode)
(let ((img-list (mapconcat (lambda (el)
(let ((link (concat "[[file:" el "]]")))
link))
my-img-dired-list
"\n\n"))
(img-num (number-to-string
(length my-img-dired-list))))
(insert (concat "* Images in " dir-name "\n\n"))
(insert (concat img-num " files:\n\n"))
(insert img-list)
(org-toggle-inline-images))
(pop-to-buffer buf)
(beginning-of-buffer))))
(with-eval-after-load 'dired
(define-key dired-mode-map (kbd "P") 'my-org-img-dired-preview))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [PATCH] ox.el: add smart quotes for Greek
@ 2021-09-19 16:30 9% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-19 16:30 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
Hi,
I attach here a tiny patch to add Greek smart quotes. Finally, I apply
the second level quotation marks that Protesilaos Stavrou proposed in this
previous thread:
https://orgmode.org/list/87o89yv1mz.fsf@cnu407c2zx.nsn-intra.net/#r
So the quotation marks setting for Greek is exactly the same as in the
case of quotation marks for Spanish.
Thanks a lot to Protesilaos, Michalis and Maxim Nikulin for their suggestions on
that thread (Maxim, sorry I did not reply to your message in the thread,
but and I didn't see it until a few days ago :-()
Best regards,
Juan Manuel
---------------------
https://juanmanuelmacias.com
[-- Attachment #2: 0001-ox.el-add-smart-quotes-for-greek.patch --]
[-- Type: text/x-patch, Size: 1843 bytes --]
From 3deb65be3d59e2ae35bd6dc9bb38b138dee926f8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 19 Sep 2021 17:58:51 +0200
Subject: [PATCH] ox.el: add smart quotes for greek
* lisp/ox.el (org-export-smart-quotes-alist): The correct quotes for Greek have been established with the help of Protesilaos Stavrou
---
lisp/ox.el | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index 5fe894569..a8014d401 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -524,7 +524,7 @@ e.g. \"H:2\"."
"The default language for export and clocktable translations, as a string.
This may have an association in
`org-clock-clocktable-language-setup',
-`org-export-smart-quotes-alist' and `org-export-dictionary'.
+`org-export-smart-quotes-' and `org-export-dictionary'.
This option can also be set with the LANGUAGE keyword."
:group 'org-export-general
:type '(string :tag "Language")
@@ -5437,6 +5437,16 @@ transcoding it."
(secondary-closing
:utf-8 "‘" :html "‘" :latex "\\grq{}" :texinfo "@quoteleft{}")
(apostrophe :utf-8 "’" :html "’"))
+ ("el"
+ (primary-opening
+ :utf-8 "«" :html "«" :latex "\\guillemotleft{}"
+ :texinfo "@guillemetleft{}")
+ (primary-closing
+ :utf-8 "»" :html "»" :latex "\\guillemotright{}"
+ :texinfo "@guillemetright{}")
+ (secondary-opening :utf-8 "“" :html "“" :latex "``" :texinfo "``")
+ (secondary-closing :utf-8 "”" :html "”" :latex "''" :texinfo "''")
+ (apostrophe :utf-8 "’" :html "’"))
("en"
(primary-opening :utf-8 "“" :html "“" :latex "``" :texinfo "``")
(primary-closing :utf-8 "”" :html "”" :latex "''" :texinfo "''")
--
2.32.0
^ permalink raw reply related [relevance 9%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-14 15:53 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-14 15:53 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
>> Subject: [PATCH] * lisp/ox-latex.el: New variable `org-latex-language-alist'
> Writing the previous message I forgot that currently there is no
> default option for the fontenc package (PdfLaTeX), e.g. T2A for
> Cyrillic. As a result it is not enough to specify just language to
> generate PDF file. From my point of view it is better to have single
> map from language code to various localization options (babel,
> polyglossia, fontenc). Unfortunately plain list
> `org-latex-language-alist' does not allow further extensions. Property
> list would make initialization not so concise, but it would make the
> map more flexible.
Sorry, I hadn't seen your other message and I ignored it...
What you say makes sense. If I'm not mistaken, there is now nothing like
an hypothetical 'org-latex-guess-fontenc', and org defaults to the T1
option. If I remember correctly (because I haven't used pdfLaTeX in
ages), the fontenc option for Greek is LGR. And I imagine there will be
many more cases. If you or anyone wants to implement that on top of my
patch, that's fine with me. I don't have much time to do it right now.
However, my opinion is the following: I think we should focus our
efforts on finding a satisfactory solution for luatex, according to
everything that has been commented in the different sub-threads on the
subject of fonts and fallback fonts. And leave the related to pdfLaTeX
in second place, if in the end LuaTeX is going to be set as the default
engine.
In any case, I personally think that org-latex-language-alist, as it is
now in this patch, is sufficient.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [PATCH] Documentation and NEWS for ` org-latex-language-alist'
@ 2022-08-08 14:39 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-08 14:39 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 347 bytes --]
Hi,
I am attaching a patch with the documentation of the new variable in the
Manual and the updated NEWS.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-doc-org-manual.org-documentation-for-org-latex-langu.patch --]
[-- Type: text/x-patch, Size: 4540 bytes --]
From 2ec740e4b2f691f619878a7b86e4874fa05d3a82 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 8 Aug 2022 16:30:01 +0200
Subject: [PATCH] doc/org-manual.org: documentation for
`org-latex-language-alist'
* etc/ORG-NEWS: update the news with the new variable.
---
doc/org-manual.org | 57 ++++++++++++++++++++++++++++++++++++++++++++--
etc/ORG-NEWS | 13 +++++++++++
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 466718e6e..5d0283bf2 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13370,19 +13370,72 @@ general options (see [[*Export Settings]]).
- =LANGUAGE= ::
#+cindex: @samp{LANGUAGE}, keyword
#+vindex: org-latex-packages-alist
+ #+vindex: org-latex-language-alist
+ #+vindex: org-export-default-language
+
+ The list of languages supported by Org is stored in the variable
+ ~org-latex-language-alist~.
+
In order to be effective, the =babel= or =polyglossia=
packages---according to the LaTeX compiler used---must be loaded
with the appropriate language as argument. This can be accomplished
by modifying the ~org-latex-packages-alist~ variable, e.g., with the
- following snippet:
+ following snippet (note that =polyglossia= does not work with
+ pdfLaTeX):
#+begin_src emacs-lisp
(add-to-list 'org-latex-packages-alist
- '("AUTO" "babel" t ("pdflatex")))
+ '("AUTO" "babel" t ("pdflatex" "xelatex" "lualatex")))
(add-to-list 'org-latex-packages-alist
'("AUTO" "polyglossia" t ("xelatex" "lualatex")))
#+end_src
+ LaTeX packages =babel= or =polyglossia= can also be loaded in a
+ document. The "AUTO" string will be replaced in both cases by the
+ appropiate value for the =LANGUAGE= keyword, if present in the
+ document, or by the value of ~org-export-default-language~. Let's
+ see some examples in one or another case.
+
+ =Babel= accepts the classic syntax and (in addition) the new syntax
+ with the =\babelprovide= command to load the languages using the new
+ =INI= files procedure. Keep in mind that there are a number of
+ languages that are only served in babel using =INI= files, so they
+ cannot be declared using the classic syntax, but only using the
+ =\babelprovide= command (see
+ http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf).
+ Valid usage examples could be:
+
+ #+begin_example
+ ,#+LATEX_HEADER: \usepackage[french,italian,AUTO]{babel}
+ #+end_example
+
+ where "AUTO" is the main language. But it can also be loaded using
+ the =\babelprovide= command:
+
+ #+begin_example
+ ,#+LATEX_HEADER: \usepackage[french,italian]{babel}
+ ,#+LATEX_HEADER: \babelprovide[import, main]{AUTO}
+ #+end_example
+
+ =Polyglossia=, for this procedure to be effective, must be loaded
+ using the same =babel= classic syntax (but note that /this is not/
+ the actual polyglossia syntax). For example, suppose a document
+ declares Polytonic Greek as the primary language, and French as the
+ secondary language. In this case, it would be expressed as:
+
+ #+begin_example
+ ,#+LANGUAGE: el-polyton
+ ,#+LATEX_HEADER: \usepackage[french,AUTO]{polyglossia}
+ #+end_example
+
+ This would produce in LaTeX (with the actual =polyglossia= syntax):
+
+ #+begin_example
+ \usepackage{polyglossia}
+ \setmainlanguage[variant=polytonic]{greek}
+ \setotherlanguage{french}
+ #+end_example
+
- =LATEX_CLASS= ::
#+cindex: @samp{LATEX_CLASS}, keyword
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 00fe101dc..fc9ac688a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -431,6 +431,19 @@ prompting for a link description. It can be a string (used as-is) or
a function (called with the same arguments as
~org-make-link-description-function~ to return a string to use).
+*** New list of languages for LaTeX export: ~org-latex-language-alist~
+
+~org-latex-language-alist~ unifies into a single list the old language
+lists for the =babel= and =polyglossia= LaTeX packages:
+~org-latex-babel-language-alist~ and
+~org-latex-polyglossia-language-alist~, respectively, which are
+declared obsolete.
+
+This new list captures the current state of art regarding language
+support in LaTeX. The new =babel= syntax for loading languages via
+=ini= files and the new command =\babelprovide= (see:
+http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf)
+are also supported.
* Version 9.5
** Important announcements and breaking changes
--
2.37.1
^ permalink raw reply related [relevance 9%]
* Re: On zero width spaces and Org syntax
@ 2021-12-03 20:30 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-03 20:30 UTC (permalink / raw)
To: Greg Minshall; +Cc: orgmode
Hi Greg, thank you for your comment,
Greg Minshall writes:
> in fact, i am always queasy when i enter ZWNBSP in a .org (or any other)
> file. some sort of "visible" sequence would be great. backwards
> compatibility might be a problem.
Yes I agree. I think that in this case, a new mark would not compromise
backward compatibility, as this presumed new mark would do the same
function as zero width space: i.e. delimit to preserve emphasis. Of
course one could go on using a zero-width space, though I keep thinking
that this is rather a puntual workaround and should not form part of the
syntax.
> your last example
>
> : [''*literature*'']
>
> seems a bit of sleight-of-hand, though. iiuc, text inside square
> brackets isn't highlighted currently, and ZWNBSP doesn't (afaict) turn
> on highlighting. (maybe there's been recent discussion, modifications
> of this?)
The idea would be to use a kind of 'protection mark', to allow something
in a context where it is not allowed: a passport ;-). As the emphasis
marks are recognized before and after a single quote, I thought that
maybe a sequence of two single quotes could function here as a
protection mark (screenshot: https://i.imgur.com/cPIH9qa.png). For
example:
#+begin_example
| Some examples where emphasis marks are not allowed | Protected emphasis marks |
|----------------------------------------------------+--------------------------|
| /meta/literature | /meta/''literature |
| [/literature/] | [''/literature/''] |
| <*literature*> | <''*literature*''> |
| meta/*literature* | meta/''*literature* |
#+end_example
With the protection marks we get (in LaTeX for example):
\emph{meta}literature
[\emph{literature}]
<\textbf{literature}>
meta/\textbf{literature}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
@ 2023-09-25 18:49 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-25 18:49 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> On 25/09/2023 01:42, Juan Manuel Macías wrote:
>> 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[...]
>> ---
>
> Does it mean that with hyperxmp you can not generate documents
> satisfying some requirements and you need namely pdfx? Is there a
> reason that .xmpdata files must be generated namely by a LaTeX engine
> and writing them by elisp code is unacceptable?
In the hyperxmp manual a comparison is made with the pdfx package and
other similar packages. Anyway, this topic deviates drastically from the
original topic of the thread. There will be users who prefer to use
hyperxmp package and users who prefer pdfx. Hyperxmp is probably more
recommended, but I don't know either one deeply, so I couldn't say. In
any case: I think the central issue is to provide support for inserting
arbitrary code before \documentclass. The pdfx example is just one valid
example (ideally Org should not put obstacles to the use of any
package). As I said, there are more cases. For example, a few packages
(I don't remember their names) are recommended to be loaded first using
\RequirePackage. And there is also the case of the \PassOptionsToPackage
command. A good practice in LaTeX documents is usually to put this
command at the very beginning of the document, to avoid messages such as
"option class for xx package error". It is placed at the very beginning
because there may be classes that already require the package involved
in the error. And one more example: a new package for LuaLaTeX was
recently uploaded to CTAN, which allows the use of shebangs in LaTeX
documents. In short, there are many heterogeneous cases, and it is the
very heterogeneity of these cases that leads to a solution similar to
LaTeX_header, IMHO. Actually, any code (except \usepackage) would be
possible before \cocumentclass.
>> For example, the newpax package, to preserve the internal links of a pdf
>> included in the document, requires putting commands like
>> \DocumentMetadata{ } before documentclass.
>
> If I understand it correctly, \DocumentMetadata is a switch to enable
> "new" LaTeX like it was for \documentclass vs. \documentstyle during
> transition to LaTeX2e from LaTeX 2.09.
https://tex.stackexchange.com/questions/686898/what-is-documentmetadata-what-key-value-pairs-does-it-take-and-when-should-i-u
(As for the transition from LaTeX2e to LaTeX 3, it seems that it is not
going to be as defined as the transition we witnessed in the leap from
LaTeX 2.09. In reality it seems that there is not going to be such a
leap but rather a "coexistence" of both worlds:
https://www.latex-project.org/publications/2020-FMi-TUB-tb128mitt-quovadis.pdf)
> If so, Org should have native support of \DocumentMetadata, not
> LATEX_PRE_HEADER or something similar.
If it were the only case of code before \documentclass, I would agree.
But, as I have already said above, the diversity of use cases makes the
implementation of /ad hoc/ solutions unviable, in my opinion.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-14 17:07 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-14 17:07 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
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 9%]
* Re: About multilingual documents
@ 2021-05-03 20:33 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-03 20:33 UTC (permalink / raw)
To: Aleksandar Dimitrov; +Cc: orgmode
Hi Aleksandar,
Thank you very much for your interesting comments. I think your idea of
applying org-babel to (multi) language support is tremendously
suggestive and, of course, more org-centric. I suppose it could be
applied also to languages within the paragraph by inline blocks... I
really liked what you propose.
Well, I admit that my marks are a bit exotic :-D. The main problem I see
is that they are not as robust as Org's own marks, since they are
controlled by an export filter. Doing some further tests, by the way, I
think it would be better to add the filter to
`org-export-filter-plain-text-functions', instead of
`...final-output-functions'. I also see that it would be convenient to
avoid their expansion in verbatim texts, with a `(unless
(org-in-verbatim-emphasis)...)'.
Anyway, I think (in general terms) it would be interesting for Org to
incorporate some multilingual support and the ability to toggle between
languages in a document, and the idea you propose seems to
me that it makes a lot of sense.
Best regards,
Juan Manuel
Aleksandar Dimitrov writes:
> Hi Juan,
>
> this sounds very interesting to me, as I, too, mostly write in Org
> and, sometimes write documents in multiple languages, usually with
> different varieties of either Latin or Cyrillic.
>
> I have some suggestions:
>
> Apart from the export, one of my biggest gripes is
> flyspell. Specifically, the fact that you have to choose one language to
> spell check the entire document with. That is insufficient in my case.
>
> I think that the syntax you're suggesting looks good, but I'm not
> sure how well it'd fit into org-mode's ecosystem. I had something in
> mind that was closer to how org-babel works (it's called *babel*
> for a reason, isn't it? :D)
>
> #+begin_src org :lang pl
> … po polsku
> #+end_src
>
> #+begin_src org :lang de
> … auf deutsch
> #+end_src
>
>
> This would make use of org-mode's edit special environment function. It
> would make it easier to persuade flyspell to do the right thing. You
> could, perhaps, add
>
> #+LANGUAGE: en
>
> to the parent document, and then org would take care to set the correct
> flyspell language (and the correct macros on LaTeX-export) and change
> these parameters in the special environments.
>
> I'm not 100% sure it should be #+begin_src org, maybe introducing a
> different special environment would be better, say #+begin_lang XX where
> XX is the ISO-code of said language, or the locale (think en_US
> vs. en_GB.)
>
> The drawback, and the clear disadvantage compared to your method is that
> this works great only when the languages are separated by paragraph
> breaks.
>
> Therefore, I think our suggestions might be somewhat orthogonal. Yours
> could be a shorthand syntax for introducing inline foreign-language
> snippets.
>
> What do you think?
>
> Regards,
> Aleks
>
> Juan Manuel Macías writes:
>
>> Hi all,
>>
>> I'm curious to see how other Org users deal with multilingual documents,
>> that is, those documents (for example, philology or linguistics texts)
>> that contain a significant number of online quotes in other languages.
>> Naturally, this makes more sense in the LaTeX backend, since it is
>> convenient to enclose these quotes in a \foreignlanguage command to
>> ensure that LaTeX at least apply the correct hyphenation patterns for
>> words in other languages.
>>
>> Luckily, in the latest versions of Babel (the Babel of LaTeX) you don't
>> need to do this when it comes to languages whose script is different
>> from Latin (e.g. Greek, languages with Cyrillic, Arabic, Hindi, etc.).
>> We can, for example, define Russian and Greek as:
>>
>> #+begin_src latex
>> \babelprovide[onchar=ids fonts,hyphenrules=russian]{russian}
>> \babelprovide[onchar=ids fonts,hyphenrules=ancientgreek]{greek}
>> #+end_src
>>
>> And also the fonts for both languages:
>>
>> #+begin_src latex
>> \babelfont[russian]{rm}{Linux Libertine O}
>> \babelfont[greek]{rm}]{Free Serif}
>> #+end_src
>>
>> For Latin-based scripts it is still necessary enclose the text in the
>> \foreignlanguage command. And now comes the question: how do Org users
>> who work in multilingual documents to obtain this command when exporting
>> to Latex?
>>
>> I usually use macros, which always tend to work fine. But lately I have
>> been testing an alternative markup system using an export filter. The
>> idea would be something like:
>>
>> %(lang) lorem ipsum dolor %()
>>
>> I start from a list of the most used languages:
>>
>> #+begin_src emacs-lisp
>> (langs '(("en" "english")
>> ("fr" "french")
>> ("de" "german")
>> ("it" "italian")
>> ("pt" "portuguese")))
>> #+end_src
>>
>> And other possible languages that Babel supports can be indicated
>> explicitly, by prepending "--":
>>
>> %(fr) ... %()
>>
>> %(--esperanto) ... %()
>>
>> (If someone wants to try it, I attach a small Org document).
>>
>> Best regards,
>>
>> Juan Manuel
>
>
--
--
^ permalink raw reply [relevance 9%]
* Re: Org-syntax: Intra-word markup
@ 2022-01-29 13:05 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-29 13:05 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Maybe we should introduce an equivalent of special blocks, but for
> inline use? Or should we modify _both_ inline export snippets and export
> blocks to allow fallback mechanism?
I find the idea of inline special blocks very interesting, but I think
there are a couple of drawbacks: since special blocks support ATTR_X,
how would that be implemented in the inline version? The most obvious
thing I can think of is to mimic inline code blocks:
my_special_block[attributes list]{content}
But it would produce a result many times too verbose. Another risk that
this would entail, IMHO, is that of the "LaTeXification" of Org...
In any case, for things like that, aren't links and macros enough? I'm
one of those who 'abuse' links for many export scenarios (I even have
written this package:
https://gitlab.com/maciaschain/org-critical-edition), and I think links
have enormous potential and versatility. John Kitchin's blog has really
helped me open my mind and explore that very productive Org component.
Macros are also a very powerful tool, except for the comma issue, which
I think is still an unfinished business and a solution should be found
one day. Still, the possibility of a special inline block is very
interesting to me.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Footnote tooltips (an attempt)
@ 2022-02-23 2:26 9% ` Juan Manuel Macías
[not found] ` <CAJcAo8tsK5o+789Wv=i6ddiSrM4fDyX8HCvjAgDLXGyLXWRWmQ@mail.gmail.com>
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-02-23 2:26 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Ypo writes:
> I love it!
> I am going to read your code, Juan Manuel, I won't understand anything
> but that function is very interesting for me, since it could be used
> too with internal links, I suppose.
Org links already have tooltips out of the box. You can also display the
tooltip in the echo area by pressing <C-h .> (`display-local-help').
If you want to try the code from my first post, please replace the
`my-org-fn-make-tooltips' function with this new version, which is much
simpler and doesn't have time-consuming issues to create or update
tooltips.
(However, I find the function I put in my second post more useful (for
my use case: I don't use the mouse very much).
#+begin_src emacs-lisp
(defun my-org-fn-make-tooltips ()
(interactive)
(org-element-map (org-element-parse-buffer) 'footnote-reference
(lambda (ref)
(let* ((label (org-element-property :label ref))
(label-from (org-element-property :begin ref))
(label-to (org-element-property :end ref))
(def (org-with-wide-buffer
(org-footnote-goto-definition label)
(let* ((e (org-element-context))
(from (org-element-property :contents-begin e))
(to (org-element-property :contents-end e)))
(buffer-substring-no-properties from to))))
(tooltip def))
(add-text-properties label-from label-to
`(help-echo
,tooltip))))
nil nil))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Experimental public branch for inline special blocks
@ 2024-03-03 20:29 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-03 20:29 UTC (permalink / raw)
To: orgmode
Hi again,
The odt backend is now complete with the `org-odt-inline-special-block'
function. Some particularities of exporting to odt:
- The only specific attribute is :odt-style, which overrides the default
style. Example:
&foo{lorem ipsum} ==> the style is "foo"
&foo[:odt-style bar]{lorem ipsum} ==> the style is "bar". Same with the
anonymous variant &_[:odt-style bar]{lorem ipsum}.
- The three global attributes supported in the LaTeX and HTML backends
are also supported in odt: `:lang', `:color' and `:smallcaps'. I have
learned that these direct format elements are in odt "automatic
styles", which must be declared before the body. I haven't thought of
any other way to do it than using a list of automatic styles that is
inserted inside `org-odt-template', with each export. Some examples with
various combinations:
&foo[:color magenta :odt-style Bold]{this is magenta and bold}
&foo[:color red :odt-style Emphasis]{this is red and emphasis}
&Underline[:color green]{this is green and underline}
&foo[:color blue]{this is blue with &_[:smallcaps t]{smallcaps}}
And a screenshot: https://i.imgur.com/KNhYQrv.png
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org to ConTeXt exporter?
@ 2020-12-29 16:05 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-29 16:05 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: orgmode
Hello, Marcin,
Marcin Borkowski <mbork@mbork.pl> writes:
> Here's the thing. Some time ago, I have dedicated about 20 minutes per
> day (sometimes less, sometimes more, but the average over the past 6
> years is about 17 minutes now) to what I call "creative writing" -
> mainly the book I was working on for the past 5 years with two more
> people (and that book is now complete) and my blog. I will try to use
> some of that time to start that tutorial, and maybe I will then publish
> it on my blog or somewhere. (I also want to get back to the book on
> Elisp I started a long time ago, but that can wait a few more weeks.)
As I said, I think a tutorial on writing an Org exporter from scratch
would be very interesting and useful. If, finally, you can find time for
it, I could do a translation to publish it on my blog in Spanish
(https://gnutas.juanmanuelmacias.com/). With my translation of Homer's
Odyssey (work in progress) and other projects, I don't have a lot of free
time, but I can always find a moment.
> But here's the thing: I'll need help. I know LaTeX very well - I've
> been using plain TeX for about 25 years now and LaTeX for about 20
> years, including writing quite a few packages and classes - but I don't
> know ConTeXt that well. (I did use it a bit, but not very extensively.)
(In my case) I have not used much ConTeXt. Really, I prefer LaTeX. It's
a personal opinion and a matter of taste, but I find ConTeXt too
"monolithic". One of the main problems it has is (I think) its huge lack
of documentation (compared to LaTeX). I suppose, in part, because his
community is smaller. However, I also think that ConTeXt has interesting
features (grid typesetting, xml integration, etc.), and it would not be
a bad idea to have an alternative to LaTeX in Org. But I don't know if
it would be something feasible in the short term, beyond the concept...
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-19 9:22 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-19 9:22 UTC (permalink / raw)
To: tomas; +Cc: orgmode
tomas@tuxteam.de writes:
> My post was rather a warning that "multi-line" will mean
> different things to different people.
Yes I agree. It is not the same as how a table is represented in Org and
how it should be rendered when exported to some typographic format like
(let's say) LaTeX. I think also 'multi-line' is a very imprecise concept
for Org tables. If we are talking about a cell whose content is a
paragraph, then for LaTeX it is no problem, with the help of the
tabularx package (in these contexts it is the best solution).
The problem here (IMHO) is a problem of discomfort of edit within Org,
when the cell has a lot of text and when we are under the 'tyranny' of
the single line. Luckily it is not a very extended issue, and the tables
in Org are much easier to view and edit than in LaTeX code, when it
comes to simple cells. What happens is that the LaTeX's `tabular(x)'
environment encompasses many more (typographic) contexts than the
concept of `table' in Org. It is a translation problem between Org and
LaTeX and vice versa...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org and Hyperbole
@ 2022-06-22 10:37 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-22 10:37 UTC (permalink / raw)
To: David Masterson; +Cc: orgmode
Hi David,
David Masterson writes:
> I haven't touched Hyperbole in ...decades...? Even then, it was
> complicated and full-featured (but I still keep it in my .emacs file).
> My discussions with Bob Weiner were interesting at the time and I really
> wanted to make use of it.
>
> As you've discovered, it integrates a lot of what Org has in, perhaps, a
> tighter fashion (which makes it more complicated, but the pain might be
> useful). The Smart Keys and Buttons are very similar to Org. The
> outliner (KOutline) is more powerful than Org, but not integrated with
> export capabilities to other formats (I think there is a way of
> exporting an outline to Org). Something that Org does not have is
> browsing capabilities for Object Oriented languages. This is an add-on
> (for C++ ?) in Hyperbole (search for OO-Browser). Since I retired, I
> don't do much programming, so Org's project management has been more
> interesting to me.
>
> It's nice to see that it's actually still being developed by Bob.
Thanks for all the interesting facts about hyperbole. I hadn't looked at
the package source code info yet, and didn't know that this is all the
work of one person. I also thought hyperbole was more recent...
It certainly has some interesting stuff. In what way is KOutline more
powerful than Org? Do you think there is any useful feature of KOutline
that could be incorporated into Org?
So far I've been able to find a couple of practical uses for this
package in my workflow. The whole window control system is very
powerful, although it would have been better if it had been a single
separate package, IMHO.
Implicit links have a lot of potential. For example, I've managed to
define some buttons for LaTeX, which recognize LaTeX commands and
environments and lead to the local TeX live documentation or
tex.stackexchange.org. It's like giving a LaTeX document a sort of hover
help. This could also be done in Org, by defining some patterns as
implicit buttons to lead to Org info pages.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org and Hyperbole
@ 2022-06-25 14:32 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-25 14:32 UTC (permalink / raw)
To: rswgnu; +Cc: orgmode
Hi, Robert,
Robert Weiner writes:
> We do like avy and as you say, Hyperbole can work with it. We try to
> avoid requiring any non-builtin Emacs packages for Hyperbole. With a
> few, we support them optionally. Unless there is a strong use case
> for utilizing avy in certain ways, we would tend to leave that to
> others to extend Hyperbole but personally I just add it in and use its
> character and line navigation sometimes. Did you have any particular
> uses in mind?
My use of the mouse within Emacs is practically nonexistent, and outside
of Emacs I have relegated the mouse to a few graphical applications such
as Gimp, Krita, Scribus, and little else. That's why I find avy
extremely handy for quickly navigating through text. By adding an action
to avy-dispatch-alist you can execute an arbitrary command once the
cursor has jumped to its target. For example, I have put this for
hyperbole in my init:
(add-to-list 'avy-dispatch-alist '(?: . (lambda (pt)
(goto-char pt)
(hkey-either))))
Thus, the typical action to activate a 'far' hyperbole button would be:
1. Call avy and insert a letter;
2. When avy's hints are displayed in the screen, I hit the colon key ":"
and then the hint letter I want to go to (an implicit button, for
example). And at the moment the associated action of that button is
executed.
For those of us who hardly use the mouse, it is really very practical,
and I think maybe mentioning that tip might be nice in the hyperbole
documentation.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-fstree.el overview over directories (but no comments are possible)
@ 2022-10-30 13:56 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-30 13:56 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Well, since I tend to forget things, and it is very time consuming to
> open files and see what is the basic content, I thought of adding to
> each directory (with subdirectories if necessary) I find useful a
> README.org file, that contains a
>
> 1. Tree of the directory and
>
> 1. a short description of the content of each file
>
> I use bookmarks.el but that is an entirely different workflow, since I
> there only save files that I find useful, but sometimes I stumble across
> a directory I created some time ago and don't recall the content of
> each file.
I see. It's not exactly what you're looking for, but I often use
filetags.el (https://github.com/DerBeutlin/filetags.el) which allows you
to add tags to files and directories in Dired. You can add multiple
tags, remove or update them. It's not a panacea, because the tags are
added directly to the file/directory name (as part of the name, I mean),
but in general it's enough for me when I want to have a file tagged in
some way. I can then locate this files by tag names using helm-locate.
Perhaps a kind of ''dired-org-view'' could be interesting, to display a
dired directory as an Org buffer, where you could add (persistent) TODO
states, notes and tags. Well, it's a sudden occurrence, I don't know to
what extent it is feasible, but in case someone feels inspired... :-)
You also have this package (haven't tried it):
https://github.com/Boruch-Baum/emacs-diredc Adds a lot of functionality
to Dired, including file preview.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: About 'inline special blocks'
@ 2022-05-23 21:06 9% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-23 21:06 UTC (permalink / raw)
To: Kaushal Modi; +Cc: orgmode
Hi, Kaushal, thanks for all your interesting comments,
Kaushal Modi writes:
> The challenging part will be deciding the syntax so that there are no
> false matches.
>
> May be reserve "inline_" for inline blocks?
>
> e.g. inline_<name>[options]{text} ?
It seems to me the most consistent option, if we continue in some way
the syntax of the inline code blocks, which would be the close relatives
of the inline special blocks. Perhaps (to shorten the syntax a bit)
'inline' could be replaced by some reserved symbol. Something like:
&_<name>[options]{text}
I think a major issue would also be how to properly compact <[options]>
so as not to result in too overloaded syntax. Maybe something like:
[latex(list of attributes) html(list of attributes)...]
?
But that is an abuse of direct formatting, which I think should always be
avoided, especially in a format-agnostic environment like Org, which is
more of a logician than a typesetter :-)
And, in any case, it is to be expected that the user will not need to
overload that part, since these hypothetical inline blocks would be
intended for short segments of text within the paragraph. I think the
most typical use case would be something like your 'mark' example.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Accessing a DLNA server through an Org link
@ 2020-12-10 22:17 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-10 22:17 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]
Hi,
I'm storing in an Org document a list of links to all my media files
(videos, music, and the like). This is a little trick that I came up
with to access the multimedia content of my raspberry's dlna server
(minidlna), using an Org link and the Javier López
'simple-dlna-browser' script
(https://github.com/javier-lopez/learn/blob/master/sh/tools/simple-dlna-browser).
You need to install socat:
#+begin_src emacs-lisp
(org-link-set-parameters
"dlna"
:follow (lambda (file)
(let ((command (concat "~/Scripts/./simple-dlna-browser.sh "
"\""
file
"\""
" | xargs vlc")))
(start-process-shell-command command nil command)))
:face '(:foreground "green4" :weight bold :underline t))
#+end_src
Tested on Arch Linux. As an external player I use vlc; `file' can simply be the name of
the file. For example, if we have gattaca.mp4 on our server, the link could be:
#+begin_src org
[[dlna:gattaca]]
#+end_src
Well, it works reasonably well. But I wonder if anyone knows of any
package or library to be able to do this (accessing a dlna server) in
a more emacs/org-centric way ...
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
@ 2021-12-06 14:59 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-06 14:59 UTC (permalink / raw)
To: Greg Minshall; +Cc: orgmode
Hi Greg,
Greg Minshall writes:
> i hope we don't adopt such an "official policy" regarding discussions on
> this list. i don't think we've had any problems where non-FSF/GNU
> topics have somehow swamped our discussions.
Not that I want to put on a censor hat, far from it :-). But this is
still an 'official' list. It's not reddit or anything like that. I think
it is necessary for the user to know what to expect here and what not to
expect. And I think there is a border between offtopic and explicitly
discussing extending Org beyond its natural limits or even flirting with
applications and software that do not respect user freedom and are
outside of GNU ethics and philosophy. And for the record, I am not
talking about Ihor's specific proposals in this thread --- which, as I
have already said, seems to me to be a commendable conciliatory effort,
although I do not share some points--- but rather from the previous
debate on the "new" name of the Org syntax, and other such things. I
think things like the 'orgdown' topic, which are not productive here,
should have their own place and forums outside here.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [tip] Org speed commands improved
@ 2022-04-26 14:00 9% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-04-26 14:00 UTC (permalink / raw)
To: orgmode
Hi all,
Org speed commands are a major productivity boost and I love them.
Lately it has occurred to me to make some modifications with the
following configuration, which I share here in case someone wants to try
it. The idea is that Org speed commands are activated anywhere in the
header (not just at the beginning of the line) *or* when point is at the
very beginning of the buffer. This, in my opinion, improves the
navigation speed:
#+begin_src emacs-lisp
(setq org-use-speed-commands
(lambda () (or (eq (point) 1)
(org-in-regexp "^\\*+\s+.+"))))
#+end_src
This also serves as a kind of write protection for the header titles. To
be able to edit them, we can use this function:
#+begin_src emacs-lisp
(defun my-org-toggle-speed-commands ()
(interactive)
(if org-use-speed-commands
(progn (setq org-use-speed-commands nil)
(message "speed-commands off"))
(setq org-use-speed-commands
(lambda () (or (eq (point) 1)
(org-in-regexp "^\\*+\s+.+"))))
(message "speed-commands on")))
(with-eval-after-load 'org
(define-key org-mode-map (kbd "M-i") 'my-org-toggle-speed-commands))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: simple request letter - help
@ 2022-05-13 20:30 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-13 20:30 UTC (permalink / raw)
To: andrés ramírez; +Cc: orgmode
andrés ramírez writes:
> Right. It is giving me an error I have NOT noticed it because the pdf is
> being generated.
Your document is probably compiled on export with the
`-intercaction=nonstopmode' option, and thus does not break the
compilation with an error. In any case, I don't really understand why
you export that part literally to LaTeX and why you add the & at
beginning of line:
& John Doe\\
& ID: XXXXXXXX
Those characters are usually reserved for tabular
environments, so LaTeX returns an error. If you want to use an &
literally in LaTeX you must escape it as \&. But if you write the
anpersand directly in Org Mode you don't need to escape it, since Org
takes care of it when it exports the document.
Also, in the signature you could also avoid direct formatting. You can
define a simple environment, with an extra space before it, if you need
to add that space. This is a very elementary example, based on your
format. Then you can use in Org a special block, with the name of the
environment:
#+LaTeX_Header: \newenvironment{signature}{\bigskip\raggedright\makebox[1.5in]{\hrulefill}\par}{\par}
#+begin_signature
John Doe
ID: XXXXXXXX
#+end_signature
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
@ 2021-12-06 7:24 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-06 7:24 UTC (permalink / raw)
To: Timothy; +Cc: emacs-orgmode
Hi Timohy,
Timothy writes:
> I don’t think Ihor is suggesting we stop indicating that org-mode is part of
> Emacs.
Of course, I am convinced that Ihor is not saying that Org is not part
of Emacs, and I have to make it clear, that I have never suggested such
a thing. What's more, I understand and applaud his conciliatory effort
on this issue, since since a series of debates and noise have arisen
here on these matters.
What worries me are the consequences of insisting here on these debates.
That is why I have underlined what Russell has commented, as I think he
is right.
On the other hand, we must not forget that Org, as part of Emacs, is
part of GNU, and this is a mailing list from the GNU project. I think
everything related to the (possible) extension of GNU Org Mode outside
of GNU Emacs (even in software incompatible with the ethics and
philosophy of the GNU project) should be considered offtopic here and be
discussed in other forums. Otherwise it would only create confusion
among users.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
@ 2022-11-10 12:40 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-10 12:40 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
Ihor Radchenko writes:
> I am trying to look into RTL language exports.
>
> I tried the following simple-minded Org file:
>
> #+title: Temp
> #+LATEX_COMPILER: lualatex
>
> #+LANGUAGE: HE
>
> \begin{equation}
> f(x) = \frac{8}{7}
> \end{equation}
>
> #+begin_src python :exports code
> for i in range(3):
> print("hello")
> #+end_src
>
> And exported to pdf (C-c C-e l o).
> Surprisingly, the output is in English.
>
> Am I missing something?
You need to explicitly load babel or polyglossia:
For polyglossia (`org-latex-guess-polyglossia-language'):
#+LaTeX_Header: \usepackage[AUTO]{polyglossia}
For babel (`org-latex-guess-babel-language'):
#+LaTeX_Header: \usepackage[bidi=basic]{babel}
#+LaTeX_Header: \babelprovide[import, main]{AUTO}
There was a discussion in an old thread about the possibility of loading
babel or polyglossia automatically (I think Maxim was in favor of it,
and brought up some possibilities). The problem is that babel's syntax
is somewhat more complex than polyglossia's, and admits many variants.
Also in babel there are languages that are loaded using the new ini file
system with the command \babelprovide. Currently,
org-latex-guess-babel-language supports babelprovide, but you need to
load the command explicitly:
#+LaTeX_Header: \babelprovide[options]{AUTO}
BTW I've noticed that the value of #+language is not case-agnostic. You
should put "he". Should it be case-agnostic? In the previous
implementation, when there were two language lists for babel and
polyglossia, neither was it.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-24 11:29 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-24 11:29 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 549 bytes --]
Ihor Radchenko writes:
> Can you please add the comments, similar to what I requested earlier.
> These magic length of 4 may be hard to grasp otherwise.
Hi Ihor,
Here is the new patch. I have realized that it is not necessary to put a
cond, since in this case it is only necessary to obtain the name of the
language for the metadata, so this new patch is simpler.
Anyway, I think I'm going to prioritize working on a new
org-latex-language-alist that is a plist, to avoid all this stuff about
numbers and lengths...
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Fix-obsolete-variables-for-babel-an.patch --]
[-- Type: text/x-patch, Size: 1497 bytes --]
From 7f3ddd0d2e6e06becd0d43575be88b77b8d699a4 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 24 Jul 2022 13:20:25 +0200
Subject: [PATCH] lisp/ox-latex.el: Fix obsolete variables for babel and
polyglossia
* (org-latex--format-spec): Use the new variable `org-latex-language-alist'.
---
lisp/ox-latex.el | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 6cd751409..aea602982 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1860,10 +1860,11 @@ INFO is a plist used as a communication channel."
(defun org-latex--format-spec (info)
"Create a format-spec for document meta-data.
INFO is a plist used as a communication channel."
- (let ((language (let ((lang (plist-get info :language)))
- (or (cdr (assoc-string lang org-latex-babel-language-alist t))
- (nth 1 (assoc-string lang org-latex-polyglossia-language-alist t))
- lang))))
+ (let ((language (let ((lang (plist-get info :language))
+ ;; Here it would suffice to obtain the second
+ ;; element, which always returns the name
+ ;; language name in `org-latex-language-alist'
+ (nth 1 (assoc-string lang org-latex-language-alist t))))))
`((?a . ,(org-export-data (plist-get info :author) info))
(?t . ,(org-export-data (plist-get info :title) info))
(?s . ,(org-export-data (plist-get info :subtitle) info))
--
2.37.1
^ permalink raw reply related [relevance 9%]
* [tip] Inline tasks as anonymous sections
@ 2022-01-08 11:32 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-08 11:32 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
Hi,
I think that a very efficient way to take advantage of inline tasks (in
the framework of document authoring and exporting) is to treat them as
anonymous sections, that is, those sections that do not have a title and
are normally separated in books by some special symbol: three asterisks
(a dinkus: https://en.wikipedia.org/wiki/Dinkus), an asterism (three
asterisks forming a triangle), or any other fancy symbol. Users can
associate their own export functions with the variables
`org-latex-format-inlinetask-function',
`org-odt-format-inlinetask-function', etc. Well, you can always add the
separation symbol directly in your text, but the advantage of using
inline task is that we can conveniently have those sections delimited,
as real sections (with properties, todo states, etc).
If anyone wants to explore this possibility, I am attaching a test org
document. I have defined two LaTeX commands: \anonsectionbreak and
\anonsectionmark; and the 'anonsection' environment[1].
[1] The Memoir class includes code for these types of divisions (see
section 6.7 FANCY ANONYMOUS BREAKS in Memoir documentation).
Best regards,
Juan Manuel
[-- Attachment #2: anon-sec-test.org --]
[-- Type: application/vnd.lotus-organizer, Size: 1862 bytes --]
^ permalink raw reply [relevance 9%]
* Re: Org-syntax: Intra-word markup
@ 2021-12-02 13:14 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-02 13:14 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, denismaier
Ihor Radchenko writes:
> Denis Maier <denismaier@mailbox.org> writes:
>
>>> Can you create an example of such scenario and post it as a bug?
>>> Probably, we just need to strip all zero-width spaces at the basic ox.el
>>> level.
>> To be clear: That's not an org bug. It's just that latex won't be able
>> such a word. If | is a zero width space, the word "hyphen|ation" is not
>> the same as "hyphenation".
>> 1. hyphenation
>> 2. hyphen|ation
>
> You are right for your example, but if we force the user to put
> *hyphen*|ation to create bold emphasis, it should not be any different
> compared to @@latex:\textbf{hyphen}ation@@. Meanwhile the *hyphen*|ation
> gets exported as \textbf{hyphen}|ation keeping the zero width space.
--
I would say that they are very random cases, and therefore difficult to
reproduce. In the 'hyphenation' example, if we load the package
showhypehns, you see that:
/hyphen/ation (with zero width sp)
and
\emph{hyphen}ation
they are cut in the same way. But differently from
hyphenation (without emphasis)
(compiled with LuaTeX).
Anyway, I have come across some curious cases. For example, a long time
ago I had defined a macro for text in other languages:
#+MACRO: lg (eval (if (org-export-derived-backend-p org-export-current-backend 'latex) (concat "@@latex:\\foreignlanguage{@@" $1 "@@latex:}{@@" "\u200B" $2 "\u200B" "@@latex:}@@") $2))
I needed to add before and after a zero width space, but doing so, the
shape of the text was altered. That can be reproduced with this example:
#+LaTeX_Header: \usepackage{showhyphens}
#+LaTeX_Header:\usepackage{lipsum,multicol}
#+LaTeX_Header:\usepackage[spanish]{babel}
#+LaTeX_Header: \def\example{\lipsum[1]}
#+LaTeX_Header: \def\zwsp{\char"200B{}}
#+OPTIONS: toc:nil
@@latex:\begin{multicols}{2}@@
@@latex:\foreignlanguage{italian}{\zwsp\example\zwsp}@@
@@latex:\foreignlanguage{italian}{\example}@@
@@latex:\end{multicols}@@
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Move or rename a file in a link
@ 2022-03-05 19:58 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-05 19:58 UTC (permalink / raw)
To: orgmode
Hi all,
I have written this simple function to move or rename a destination file
in an external link at point. I share it here in case it is useful to
someone.
Best regards,
Juan Manuel
#+begin_src emacs-lisp
(defun my-org-replace-link-file (from to)
(save-excursion
(goto-char (point-min))
(while (re-search-forward org-bracket-link-regexp nil t)
(when (string-match-p from (match-string 1))
(replace-match (concat "[[file:" to "]]"))))))
(defun my-org-rename-link-file-at-point ()
"Rename or move a file in an external link at point and
update the link path"
(interactive)
(let* ((curr-dir (abbreviate-file-name default-directory))
(current-path (org-element-property :path (org-element-context)))
(new-path (read-file-name "Rename file at point to: " current-path)))
(rename-file current-path new-path)
(message (concat "moved to: " new-path))
(if (directory-name-p new-path)
(setq new-path (concat new-path (file-name-nondirectory current-path)))
(setq new-path new-path))
(my-org-replace-link-file current-path
(replace-regexp-in-string curr-dir "" new-path))))
#+end_src
^ permalink raw reply [relevance 9%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-19 10:53 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-19 10:53 UTC (permalink / raw)
To: tomas; +Cc: orgmode
tomas@tuxteam.de writes:
> For export formats, there could be (yet another) "signal" to convey
> "new paragraph here" which then is the exporter's job. Perhaps an
> empty line (as is traditional in TeX) or something else.
I think that signal would be a good solution within a single line. For
example, for an emergency a simple macro would suffice, something as:
#+MACRO: par @@latex:\par{}@@
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 ;-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: including one double quote in an anonymous footnote?
@ 2022-02-26 19:20 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-26 19:20 UTC (permalink / raw)
To: Greg Minshall; +Cc: orgmode
Greg Minshall writes:
> Juan Manuel,
>
>> I can confirm that behavior. One possible solution is to use an entity
>> (M-x org-entities-help):
>
> thanks very much -- that does the trick for my case.
In any case, I don't know if that behavior should be considered a bug. I
say this because other constructions with an unbalanced element,
although org does not fontify them well, they are exported correctly:
this is a test[fn::(this is an inline footnote]
this is a test[fn::{this is an inline footnote]
== LaTeX ==>
this is a test\footnote{(this is an inline footnote}
this is a test\footnote{\{this is an inline footnote}
Instead, if you do <M-: (org-element-context)> on your example,
org-element-context doesn't recognize this as a footnote reference:
this is a test[fn::"this is an inline footnote]
Looking at `org-element-footnote-reference-parser', I'd say the problem
is with:
...
(with-syntax-table org-element--pair-square-table
(ignore-errors (scan-lists (point) 1 0)))
...
If there is an unbalanced double quote inside a bracket construction,
that expression returns nil and not the position after the final
bracket. But I don't know how to go on :-(.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-15 18:21 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-15 18:21 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim
Maxim Nikulin writes:
> I can reproduce the issue with emacs-27.1 from ubuntu-21.04 beta live
> image running in qemu. Org mode is current git HEAD. It seems that
> something is changed in emacs since locale is correct:
>
> ubuntu@ubuntu:~$ printf '%s- v\n- /v/\n- a\n- /a/\n' '' \
> | LANG=C.UTF-8 sort
> - /a/
> - /v/
> - a
> - v
> ubuntu@ubuntu:~$ printf '%s- v\n- /v/\n- a\n- /a/\n' '' \
> | LANG=es_ES.UTF-8 sort
> - /a/
> - a
> - /v/
> - v
>
> Concerning org-sort-list, I do not see any problem with en_US.UTF-8,
> it_IT.UTF-8, and ru_RU.UTF-8 locales. However emphasized items are
> sorted first for at least es_ES.UTF-8, es_MX.UTF-8, and es_US.UTF-8.
> I have found some evidence that the problem is on the org side
>
> cat list.el
> (message "%S" (sort '("- /v/" "- v" "- a" "- /a/")
> #'string-collate-lessp))
>
> LC_ALL=C.UTF-8 emacs --batch -Q -l list.el
> ("- /a/" "- /v/" "- a" "- v")
>
> LC_ALL=en_US.UTF-8 emacs --batch -Q -l list.el
> ("- /a/" "- a" "- /v/" "- v")
>
> LC_ALL=es_ES.UTF-8 emacs --batch -Q -l list.el
> ("- /a/" "- a" "- /v/" "- v")
>
> So even string-collate-lessp works as expected.
>
> I'm puzzled why the problem is specific to org-sort-list and namely to
> Spanish locales.
>
>
Well that's pretty weird ... I wonder if the (spurious?) spaces in
`org-sort-remove-invisible' that I mentioned at the beginning may be
helpful to keep a track, or if it's just something that masks the
problem.
Anyway, I have noticed that the only space that seems determinant (from
some way that escapes me) is this (where I put the @ sign):
org-emph-re (lambda (m) (format "@%s " (match-string 4 m)))
Following your examples, it occurred to me to try this, which I don't
know if it is relevant or if I have entered a dead end:
#+begin_src emacs-lisp :tangle list-var.el
(message "%S" (sort '("-\s\sv" "-\sv" "-\sa" "-\s\sa")
#'string-collate-lessp))
#+end_src
#+begin_src sh
exec 2>&1
LC_ALL=en_US.UTF-8 emacs --batch -Q -l list-var.el
#+end_src
#+RESULTS:
: - a" "- a" "- v" "- v
#+begin_src sh
exec 2>&1
LC_ALL=es_ES.UTF-8 emacs --batch -Q -l list-var.el
#+end_src
#+RESULTS:
: - a" "- v" "- a" "- v
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [patch] ox-latex.el: add `:options' LaTeX attribute to tables
@ 2021-10-26 16:05 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-26 16:05 UTC (permalink / raw)
To: orgmode; +Cc: Vikas Rawal
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
Hi,
The `:options' attr. allows adding an optional argument with various
table options (between brackets in LaTeX export), since certain tabular
environments, such as `longtblr' of the `tabularray' LaTeX package,
provides this structure (see:
https://list.orgmode.org/CALtzAB1yM+uG_xHghCxTLRX5mgbzNvT5+PO=DuaBB28nCsVqEA@mail.gmail.com/#r)
Example:
#+ATTR_LATEX: :environment longtblr
#+ATTR_LATEX: :align colspec = {XXX}, width = 0.85\linewidth
#+ATTR_LATEX: :options remark{Note} = {Lorem ipsum dolor sit amet}
==> \begin{longtblr}[remark{Note} = {Lorem ipsum dolor sit amet}]{colspec = {XXX}, width = 0.85\linewidth}
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-latex.el-add-options-latex-attribute-to-tables.patch --]
[-- Type: text/x-patch, Size: 1495 bytes --]
From 9b51d999029f91adc93a6009bc3ddf56bba7ba4a Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 26 Oct 2021 12:29:55 +0200
Subject: [PATCH] ox-latex.el: add `options' latex attribute to tables
* lisp/ox-latex.el (org-latex--org-table): The `:options' LaTeX
attribute allows adding an optional argument (\begin{env}[opt]), since
certain tabular environments, such as longtblr, accept optional
arguments.
---
lisp/ox-latex.el | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 3e3967033..409d92164 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3314,6 +3314,7 @@ This function assumes TABLE has `org' as its `:type' property and
`table' as its `:mode' attribute."
(let* ((attr (org-export-read-attribute :attr_latex table))
(alignment (org-latex--align-string table info))
+ (opt (org-export-read-attribute :attr_latex table :options))
(table-env (or (plist-get attr :environment)
(plist-get info :latex-default-table-environment)))
(width
@@ -3343,8 +3344,9 @@ This function assumes TABLE has `org' as its `:type' property and
(format "\\end{%s}" table-env)
(and fontsize "}"))))
(t
- (let ((output (format "\\begin{%s}%s{%s}\n%s\\end{%s}"
+ (let ((output (format "\\begin{%s}%s%s{%s}\n%s\\end{%s}"
table-env
+ (if opt (format "[%s]" opt) "")
width
alignment
contents
--
2.33.0
^ permalink raw reply related [relevance 9%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
[not found] ` <87tunlxws3.fsf@ucl.ac.uk>
@ 2021-05-02 11:09 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-02 11:09 UTC (permalink / raw)
To: Eric S Fraga; +Cc: Bastien, orgmode, TEC
Hi Eric and all,
Thank you for your comments.
Eric S Fraga writes:
> What is being proposed looks reasonable to me. I don't use =verse= very
> often but have used it now and again and I can particular see the need
> for numbering and centring, in particular.
Indeed, optical centering is the correct typographic representation for
poetry and poetry quotes. There would only be a couple exceptions: a)
Certain types of avant-garde poetry (whose representation on paper is
usually freer) and b) those poems whose verses spill over the margins
and span several lines (in such case, the attribute :versewidth would
have to take the value \textwidth, and then the verse package takes care
of adjusting the overflowing part of the verses).
Here I have uploaded two very illustrative examples of optical
centering, two pages from a Tolkien book (/The Monsters and the Critics
and Other Essays/) and another page from a book that I recently
typesetted (here also includes verse numbering):
https://imgur.com/a/cGi4CpD
> Is the verse package loaded automatically already? I did not see any
> change in the patch to that aspect and when I export a simple test, the
> package is not loaded.
For now, you need to load the verse package or add it to
org-latex-packages-alist...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [question] lisp code in :results header arg.?
@ 2021-02-16 16:30 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-16 16:30 UTC (permalink / raw)
To: orgmode
Hi,
I'm exploring some ways to include a complex LaTeX preamble using source
blocks. Consider this (code at the end of this message), that works fine.
My question is: In order to do it all in a single block, would there be
any way to pass the output of the first block as an argument to a
function, and put that function as a header arg (results)...?
Best Regards,
Juan Manuel
#+NAME:preamble
#+begin_src latex :results silent :exports results
\usepackage{luacode}
\usepackage{fontspec}
\directlua
{
fonts.handlers.otf.addfeature
{
name = "ktest",
type = "kern",
data =
{
["A"] = { ["V"] = -45 },
},
}
}
\setmainfont{Linux Libertine O}
[RawFeature={+ktest}]
#+end_src
#+begin_src emacs-lisp :var x=preamble :results raw :exports results
(let* ((lines (split-string x "\n" nil))
(headers (mapconcat (lambda
(line)
(unless (equal line "")
(format "#+LaTeX_Header: %s" line)))
lines "\n")))
headers)
#+end_src
#+RESULTS:
#+LaTeX_Header: \usepackage{luacode}
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \directlua
#+LaTeX_Header: {
#+LaTeX_Header: fonts.handlers.otf.addfeature
#+LaTeX_Header: {
#+LaTeX_Header: name = "ktest",
#+LaTeX_Header: type = "kern",
#+LaTeX_Header: data =
#+LaTeX_Header: {
#+LaTeX_Header: ["A"] = { ["V"] = -45 },
#+LaTeX_Header: },
#+LaTeX_Header: }
#+LaTeX_Header: }
#+LaTeX_Header: \setmainfont{Linux Libertine O}
#+LaTeX_Header: [RawFeature={+ktest}]
^ permalink raw reply [relevance 9%]
* Re: About 'inline special blocks'
@ 2022-06-19 20:15 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-19 20:15 UTC (permalink / raw)
To: Christian Moe; +Cc: orgmode
Hi, Christian,
Thanks for your comments.
Christian Moe writes:
> Hi,
>
> This makes sense to me.
>
> Note: For the html output in your example, I expect you don't mean
> <name>contents></name>, but <span class="name">contents</span>. That
> would give the desired custom style controle of the output, and would
> parallel the behavior of special blocks.
You are absolutely right, it is my fault. These days I'm doing a work
with a lot of xml, and I've mixed things up in my head :-). In html the
expected form is as you say. Apologize for the confusion.
> If "inline special blocks" will be able to nest, they will have an
> advantage over org macros, which cannot.
>
> Apart from nesting, an org macro could do the same job, but less
> elegantly. The suggested inline syntax would not require commas to be
> escaped in the contents. And it would be somewhat more concise and far
> more legible, as illustrated in the below example (with working macros,
> imagined inline special blocks, and a CSS implementation):
>
> #+begin_example
> #+macro: fmt @@html:<span class="$1">$2</span>@@@@latex:\$1{$2}@@@@odt:<text:span text:style-name="$1">$2</text:span>@@
> #+html_head: <style>.highlight {background-color: yellow;}
> #+html_head: .smallcaps {font-variant: small-caps;}</style>
>
> This is some {{{fmt(highlight, highlighted text)}}} and this is some
> {{{fmt(smallcaps, text in small caps)}}}.
>
> This is some %[highlight]{highlighted text} and this is some
> %[smallcaps]{text in small caps}.
> #+end_example
I have used macros a lot in the past for these purposes. But the problem
of having to escape commas and the somewhat confusing (and ugly) syntax
of macros has led me to rarely use them now. Links have been a good
replacement for me, but they still have their limitations (the most
important, as Ihor commented, not being able to include a link within
the description. But we can't put footnotes either). I actually think
that inline special blocks could be tremendously useful and versatile.
And, in syntactic terms, an important point in favor of Org against
Markdown, which if I'm not mistaken does not have anything similar (I
hardly use md, so I'm not very aware).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Write Markdown in Org mode
@ 2021-06-12 12:35 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-12 12:35 UTC (permalink / raw)
To: leo; +Cc: orgmode
Hi Leo,
leo writes:
> Hi there
>
> I write a lot of Markdown notes. At the moment I use Melpa’s markdown-mode, but I am considering switching to Org mode.
>
> But I’m not sure whether Org mode supports this. In the manual I found an option to *export* to Markdown, but I planning to *write* the notes directly as Markdown.
>
> Is this possible with Org mode?
>
> Many thanks!
>
I do not know the characteristics or the contexts of your workflow, but
seen the case from the outside, from what you comment I would say that
it would not have a lot of sense for you to write your Org docs in
Markdown, since Org is also a lightweight markup language, but much more
powerful than Markdown. Org mode is intended to write in Org syntax.
I started writing my notes in Markdown, and when I migrated to Org, I
converted all my old Markdown notes to Org via pandoc.
Anyway, inside an Org document you can write Markdown using a source
block:
#+begin_src markdown
your text in markdown...
#+end_src
If you do C-c ' inside the block, you can edit it in another buffer with
the markdown mode activated[1].
You can also generate a * .md file from that block (see
https://orgmode.org/manual/Extracting-Source-Code.html):
#+begin_src markdown :tangle my-file.md
your text in markdown...
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Explicit page breaks (was: Create in Org a bilingual book with facing pages)
@ 2022-09-28 7:50 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-28 7:50 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>>> 1. \clearpage command, which reminds me about
>>> https://orgmode.org/list/87mtamjrft.fsf@localhost
>>> May it be useful to have page break syntax element in Org?
>>
>> I really don't have an opinion at the moment... As a user I try to put
>> as few direct LaTeX commands as possible: commands like \newpage,
>> \pagebreak, \clearpage, \bigskip, \quad, etc. Whenever I can, I
>> prefer to control spaces and page breaks using more general macros. And,
>> when I put these commands, the fact of resorting to an export snippet
>> does not usually bother me, since they are not very verbose commands.
>> But I don't know what other users will think...
>
> Fine-tuning commands should indeed be dedicated to specific export
> backends. It is generally meaningless to have \clearpage in html export.
>
> However, \pagebreak specifically is something people use in plain text
> files, and it may be useful for odt exports.
I agree. In the case of odt its xml is a pain for me to deal with, and
usually I have to open an odt document in Emacs and look at the
contents.xml file to find the (probably) correct tag Between that
hideous labyrinth of tags :-)
Well, considering that the most sensible place (IMO) to introduce an
explicit page break would be before almost anything that isn't a section
(since in sections page breaks should be defined by style), how about
something like this:
#+ATTR_LATEX: :pagebreak \clearpage
#+ATTR_ODT: :pagebreak t
Lorem ipsum dolor sit amet, consectetuer adipiscing elit...
(In the case of LaTeX the expected value of :pagebreak could be any of
several commands that LaTeX has for page breaking (or any other
arbitrary code). And if you put :pagebreak t, the default value would be
\pagebreak.
And to introduce an explicit break before a heading, the above could be
added as a property.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-mode export to (latex) PDF
@ 2021-07-14 19:29 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-14 19:29 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Maxim Nikulin writes:
> It perfectly suits for e.g. a book when camera ready variant is
> required. For routine notes it is better to keep from defaults as
> minimal as possible to minimize problems that may arise a decade
> later. I would prefer to avoid Linux Libertine if I am going to send
> source file to a colleague having another OS.
Linux Libertine (otf version) is included in TeX live. Indeed TeX live
includes a extensive catalog of otf and ttf fonts to be used in LuaTeX
or XeTeX:
https://tug.org/FontCatalogue/opentypefonts.html
As for the original topic of this thread, I am not aware of Japanese
nor of its typographic norms, but it may be interesting to take a look
at the luatexja package: https://ctan.org/pkg/luatexja?lang=en
As for LuaTeX, I think this engine has been a great revolution within
the TeX ecosystem, to the point that it is setting the standard of
everything that is coming new and what is to come. I guess that LuaTeX
will be the natural replacement for pdfTeX (in fact, LuaTeX evolved from
pdfTeX and also took elements from another lesser known, experimental
TeX engine, Omega, which was the first attempt, quite avant-garde, to
create a TeX engine totally Unicode based:
https://en.wikipedia.org/wiki/Omega_(TeX).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-26 16:19 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-26 16:19 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
Hi Ihor,
A thousand apologies for my horrible carelessness with the parentheses.
I should have checked the code. Here goes the patch again corrected. I
hope it's alright now.
Ihor Radchenko writes:
> Also, the original code contained the clause:
> (or (get lang from the alist1)
> (get lang from the alist2)
> lang ; Fallback to provided language if not known.
> )
>
> Your variant does not have the fallback part. Is it intentional?
Yes, I removed it because I thought it was not necessary, because after
all the user must put a supported language as the value of #+language.
Anyway, in case it breaks something backwards I have replaced it. Now
the or expression is:
(or (nth 1 (assoc-string lang org-latex-language-alist t))
lang)
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Remove-Babel-and-Polyglossia-alists.patch --]
[-- Type: text/x-patch, Size: 1324 bytes --]
From 483cf69e0ca56c560c3bd53db13887a63d529ec9 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 26 Jul 2022 18:01:52 +0200
Subject: [PATCH] lisp/ox-latex.el: Remove Babel and Polyglossia alists
* (org-latex--format-spec): The new variable is now `org-latex-language-alist'
---
lisp/ox-latex.el | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 121a3f84c..14728f0ba 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1861,8 +1861,10 @@ INFO is a plist used as a communication channel."
"Create a format-spec for document meta-data.
INFO is a plist used as a communication channel."
(let ((language (let ((lang (plist-get info :language)))
- (or (cdr (assoc-string lang org-latex-babel-language-alist t))
- (nth 1 (assoc-string lang org-latex-polyglossia-language-alist t))
+ ;; Here it would suffice to obtain the second
+ ;; element, which always returns the name
+ ;; language name in `org-latex-language-alist'
+ (or (nth 1 (assoc-string lang org-latex-language-alist t))
lang))))
`((?a . ,(org-export-data (plist-get info :author) info))
(?t . ,(org-export-data (plist-get info :title) info))
--
2.37.1
^ permalink raw reply related [relevance 9%]
* Re: how to export to odt with 11 or 10 pt fonts? Default font setting
@ 2021-10-07 11:24 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-07 11:24 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode, Eric S Fraga
Uwe Brauer writes:
> I searched about google, but it seems that the only way to have a 10 or
> 11 pt font size is, again, by using styles. Am I right?
Yes, you are right. Word processors handle paragraph and character
styles. Anything that is not styled is applied by direct formatting,
manually, which is often bad practice.
Fun fact: 11pt (for example) in libreoffice or M$ Word is not the same
as 11pt in LaTeX. The reason is that TeX uses by default the classic
point "pt", traditionally used in English-speaking countries. 12pt=1pc
(pica). Word processors and DTP programs like InDesign or QuarkXpress
use the postscript point, which is somewhat higher. In TeX the
postscript point is called 'big point' (bp). There is also the didot
point, which in TeX is called "dd" (12dd = 1 cicero). See:
https://github.com/tweh/tex-units
With the calc-units package you can easily convert between these TeX
units in Elisp. For instance:
(require 'calc-units)
(calc-eval (math-convert-units (calc-eval "11texpt" 'raw) (calc-eval
"texbp" 'raw)))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [proof of concept] inline language blocks
@ 2024-02-20 20:35 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-20 20:35 UTC (permalink / raw)
To: orgmode
Hi,
I'm dedicating a local branch to developing this proof of concept and
testing it in my workflow, so far with good results. The basic idea is
to provide Org with multilingual features and various methods for
selecting languages.
The inline-language-block is intended for small segments of text in a
language other than the main language. They can span several lines but
not more than a paragraph. They can be used for in-line textual quotes,
glosses, etc. They are constructions equivalent to, for example, LaTeX
\foreignlanguage{french}{text} or HTML <span lang=fr>text</span>.
I have thought of a syntax that is as least intrusive as possible, so as
not to make reading uncomfortable. I have tried the following:
:fr{some text in French} :it{some text in Italian} :la{some text in Latin}
You can also use a literal term instead of a language code:
:klingon!{some text in Klingon}
The blocks can be nested:
:klingon!{Some text in Klingon with :it{some text in Italian}}
And they may include other elements:
:el{Some text in Greek with a {{{macro}}} and a [[link]]}
To this end, I have defined the following element:
#+begin_src emacs-lisp
(defun org-element-inline-language-block-parser ()
"Parse inline language block at point.
When at an inline language block, return a new syntax node of
`inline-language-block' type containing `:begin', `:end',
`:type', `:contents-begin', `:contents-end' and `:post-blank' as
properties. Otherwise, return nil.
Assume point is at the beginning of the block."
(save-excursion
(when (looking-at ":\\([A-Za-z!]+\\){")
(goto-char (match-end 0))
(let* ((begin (match-beginning 0))
(contents-begin (match-end 0))
(type (org-element--get-cached-string
(match-string-no-properties 1)))
(contents-end
(progn
(goto-char (- contents-begin 1))
(org-element--parse-paired-brackets ?\{)
(- (point) 1)))
(post-blank (skip-chars-forward " \t"))
(end (point)))
(when contents-end
(org-element-create
'inline-language-block
(list :type type
:contents-begin contents-begin
:contents-end contents-end
:begin begin
:end end
:post-blank post-blank)))))))
(defun org-element-inline-language-block-interpreter (inline-language-block contents)
"Interpret INLINE LANGUAGE BLOCK object as Org syntax."
(format ":%s{%s}"
(org-element-property :type inline-language-block)
contents))
#+end_src
And, for now, this function for ox-latex:
#+begin_src emacs-lisp
(defun org-latex-inline-language-block (inline-language-block contents info)
"Transcode an INLINE LANGUAGE BLOCK element from Org to LaTeX.
CONTENTS holds the contents of the block. INFO is a plist
holding contextual information."
(let ((type (org-element-property :type inline-language-block)))
(if (string-match-p "!" type)
(format "\\foreignlanguage{%s}{%s}"
(replace-regexp-in-string "!" "" type)
contents)
(let* ((plist (cdr
(assoc type org-latex-language-alist)))
(language (plist-get plist :babel))
(language-ini-only (plist-get plist :babel-ini-only))
(language-ini-alt (plist-get plist :babel-ini-alt))
(lang (or language language-ini-only language-ini-alt)))
(format "\\foreignlanguage{%s}{%s}" lang contents)))))
#+end_src
Opinions, suggestions, feedback, ideas?
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 9%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
@ 2023-09-26 19:12 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-26 19:12 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Thomas S. Dye
Max Nikulin writes:
> I just have checked that a dirty hack with a few lines of code for
> `org-export-filter-final-output-functions' allows to insert arbitrary
> text to the beginning of export result. Perhaps a more elegant solution
> exists, but I admit it is not a straightforward way. At least it is
> possible.
And it is also possible by simply defining a new class (in Org
terminology, not LaTeX). My usual class is an almost empty one, without
documentclass and without packages, because I don't want org to write
the preamble for me. But I think this is not the point.
> I do not mind that generation of preamble should be more flexible, but I
> consider LATEX_PRE_HEADER as an ad hoc solution, so I am trying to find
> a better variant. That is why I asked for details concerning particular
> use cases.
IMHO, LaTeX_pre_header is obvious and transparent to the user: a version
of LaTeX_header that behaves exactly the same, except that it exports
the lines before \documentclass. It is simple and requires little code
to implement, and it is used for all cases of code before the
declaration of the class, since its syntax is consistent with
LaTeX_header. And its use does not require further explanation. You can
even play with constructions like:
#+NAME: pre
#+begin_src latex :exports none
(some stuff)
#+end_src
#+begin_src latex :noweb yes :results raw
,#+LaTeX_pre_header: <<pre>>
#+end_src
> I remember recipes like "put \usepackage{cmap} immediately after
> \documentclass" (nowadays this particular one should not be necessary).
> So I would prefer to avoid keywords per each chunk of preamble code.
I think that this would not be the case. This is not just any part of
the preamble, but a fairly definite part. Broadly speaking, LaTeX_header
would take care of what is after \documenclass (the axis of a LaTeX
document); LaTeX_pre_header would do it of anything that may have come
before. And both provide a less constricted preamble for advanced use of
LaTeX. Frankly, I can't think of a simpler solution.
> \begin{filecontents*} from the original post is not convincing.
Are you not convinced by some instructions that are included in the
official documentation of a LaTeX package (pdfx)?
https://i.imgur.com/NdLWmwc.png
The thing is that here it is not a question of whether something can be
done in this way or in another better way. This is how a given package
recommends doing it. If the user wants to use that specific package, she/he
will have to follow these instructions. It's more. I am thinking, for
example, of the case in which the user has to obtain a * tex file, not a
PDF, because she/he is collaborating with more people who do not use
Org, but do use that code in the * tex document.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
@ 2021-04-06 19:13 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-06 19:13 UTC (permalink / raw)
To: physiculus; +Cc: orgmode
Hi physiculus,
physiculus writes:
> Hello,
> i use LuaTex / LuaLatex successfully after some configs and readings.
> The result (quality and speed) for me is better then with the old latex engine.
> I'm satisfied.
> BUT one thing isn't working and as far as i read here, there is no
> solution yet :-(
> The latex-preview inside org-mode is not possible, because it seems,
> that org-mode needs the dvi subprocess for running the neccessary tools.
> With LuaLatex there is no dvi file, because it produces a pdf right
> away.
> Any solution will be wellcome.
I have this in my ~/.emacs:
#+begin_src emacs-lisp
(setq luamagick
'(luamagick
:programs ("lualatex" "convert")
:description "pdf > png"
:message "you need to install lualatex and imagemagick."
:use-xcolor t
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.7 . 1.5)
:latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
(add-to-list 'org-preview-latex-process-alist luamagick)
(setq luasvg
'(luasvg
:programs ("lualatex" "dvisvgm")
:description "dvi > svg"
:message "you need to install lualatex and dvisvgm."
:use-xcolor t
:image-input-type "dvi"
:image-output-type "svg"
:image-size-adjust (1.7 . 1.5)
:latex-compiler ("lualatex -interaction nonstopmode -output-format dvi -output-directory %o %f")
:image-converter ("dvisvgm %f -n -b min -c %S -o %O")))
(add-to-list 'org-preview-latex-process-alist luasvg)
(setq org-preview-latex-default-process 'luasvg)
#+end_src
You can set 'org-preview-latex-default-process' to luasvg or luamagick
Best regards,
Juan Manuel
--
--
------------------------------------------------------
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 9%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
@ 2022-06-11 11:20 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-11 11:20 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi, Ihor, thanks for your comments,
Ihor Radchenko writes:
> Wouldn't it be better to supply a customization for
> org-babel-process-comment-text instead?
>
> I do not feel that per-src-block control on the comment type makes much
> sense here.
My first approach was actually to define some options for
org-babel-process-comment. But I noticed that a header with properties,
for example:
* Header
:PROPERTIES:
:FOO: var
:END:
is interpreted as:
;; Header
;; :FOO: var
I think the culprit is the '(match-end 0)' in
org-babel-tangle-single-block:
...
(comment
(when (or (string= "both" (cdr (assq :comments params)))
(string= "org" (cdr (assq :comments params))))
;; From the previous heading or code-block end
(funcall
org-babel-process-comment-text
(buffer-substring
(max (condition-case nil
(save-excursion
(org-back-to-heading t) ; Sets match data
(match-end 0)) ;; <=========
(error (point-min)))
(save-excursion
(if (re-search-backward
org-babel-src-block-regexp nil t)
(match-end 0) ;; <=========
(point-min))))
(point)))))
...
So I couldn't think of any other solution than to put the change there,
so as not to break backwards compatibility. But it is a somewhat tricky
solution...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
@ 2022-06-12 19:55 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-12 19:55 UTC (permalink / raw)
To: Rudolf Adamkovič; +Cc: orgmode
Hi, Rudolph, thanks for your comments,
Rudolf Adamkovič writes:
> Juan, hi!
>
> I do not understand the meaning of ASCII. How will such comments look
> like? Will they include at least the file name? If so, those can
> contain Unicode characters, right?
The main motivation for proposing this new option is that when I choose
the ':comments org' option, all the Org metadata that is close to the
code block in my org file are 'preserved', so comments in the source
file are somewhat awkward to read (as simple comments). My idea is that
with this new option the comments pass as plain text, without property
drawers, keywords, etc.
For example, that a header like this:
------------------------------------
* Variables
:PROPERTIES:
:foo: var
:END:
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
hendrerit tempor tellus. Donec pretium posuere tellus.
------------------------------------
does not pass to the source file like this:
------------------------------------
;; Variables
;; :PROPERTIES:
;; :foo: var
;; :END:
;; Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
;; hendrerit tempor tellus. Donec pretium posuere tellus.
------------------------------------
but in this way:
------------------------------------
;; Variables
;; ==========
;; Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
;; hendrerit tempor tellus. Donec pretium posuere tellus.
------------------------------------
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Filter to put decorative initial letters
@ 2022-01-07 0:41 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-07 0:41 UTC (permalink / raw)
To: orgmode
Hi,
These past holidays I've been experimenting with some little useful, but
fun stuff. This is an export filter to put a decorative initial letter
in the first paragraphs of the first level sections, using the LaTeX
package lettrine (https://www.ctan.org/pkg/lettrine).
A screenshot: https://i.imgur.com/mLQVHFC.png
#+BIND: org-export-filter-parse-tree-functions (lettrine)
#+begin_src emacs-lisp :exports results :results none
(defun lettrine (tree backend info)
(when (org-export-derived-backend-p backend 'latex)
(org-element-map tree 'headline
(lambda (section)
(when (eq 1 (org-element-property :level section))
(let* ((contents (org-element-interpret-data (org-element-contents section)))
(lettrine-opt (org-export-get-node-property :LETTRINE_OPTIONS section t))
(contents-lettrine (with-temp-buffer
(insert contents)
(save-excursion
(goto-char (point-min))
(re-search-forward "\\(\\b.\\)\\([^\s]+\\b\\)" nil t)
(replace-match (concat "\\\\lettrine"
(if lettrine-opt (format "[%s]"
lettrine-opt) "")
"{" "\\1" "}" "{" "\\2" "}")
t nil)
(org-element-parse-buffer)))))
(apply #'org-element-set-contents
section
(list contents-lettrine)))))
info)
tree))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Playing down the text in org-mode
[not found] ` <87iluncrr6.fsf@posteo.net-MtK5wx2----2>
@ 2022-01-13 20:20 9% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-13 20:20 UTC (permalink / raw)
To: fatiparty; +Cc: orgmode
fatiparty@tutanota.com writes:
> I am discussing something slightly different.
>
> Here is normal text within -which there is some understated text- before continuing with normal text.
Yes, it seems that I have understood you horribly wrong, sorry for the
noise (it must be the effects of the third modern vaccine that they gave
me yesterday :-)
In short, what you want is that a part of the text is "obscured" in some
way with respect to the main body text, and you would like Org to have
some marks for it. I see an important basic problem: there are many
procedures to reduce the reading importance of a text: simply pass that
text to a footnote, use dashes, parentheses or brackets, put the text in
a smaller size (which is the usual when these passages are isolated
paragraphs). I think it is better to define all these questions in the
output formats, through post-processing, and in Org use macros, custom
links, special blocks, the procedure that John has shared here, etc. But a
"universal" no-emphasis mark doesn't seem viable to me, IMHO.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [PATCH] Intra-word markup: \relax
@ 2022-01-28 13:13 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-28 13:13 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> I have an idea how to implement *intra*/word/ markup with minimal
> change of Org syntax. At first I had a hope that it is enough to
> introduce \relax entity that expands to empty string, but it does not
> work for second part of words: *intra*\relax{}/word/ is exported to
> <b>intra</b>/word/.
> So it is necessary to support consuming spaces after such entity
> similar to TeX commands:
> *intra*\relax /word/
> In Org "a\_ b" already behaves in the same way.
>
> I do not like zero-width spaces since they are invisible, so they are
> not really "text" markup. Moreover, it is better to filter them out
> during export.
>
> Another failed idea was to use export snippet or a macro for such purpose:
> #+macro sep $1
> *intra*{{{sep()}}}/word/, *intra*@@html:@@/word/
>
> Important point that suggested solution works for all export backends.
> I do not consider explicit export snippets as a workaround since it
> requires code for all backends in org files.
Maxim, I find the idea of \relax entity interesting. The only (minor)
drawback I find (in normal use, I mean) is the verbosity it adds.
In my case, I have already given up on the problem of marks inside words
:-(. My personal opinion: I think that, unless a completely
'revolutionary' solution emerges, it is better to leave the matter as it
is, and consider this a feature of Org rather than a bug. I suspect that
a single solution could not satisfy all tastes or all possible
scenarios, so maybe it would be nice to put a list of solutions
(including this one and also the zero space thing, and others that have
arisen or may arise) somewhere (perhaps in the manual?). What doesn't
quite convince me (and I agree with you on that) is recommending zero
width space as a sort of 'official' escape character. For the reasons
you have expressed, which I think are very fair.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Save Gnus attachments to Org using org-attach and helm-org-ql
@ 2022-04-10 8:49 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-10 8:49 UTC (permalink / raw)
To: orgmode
Hi all,
I thought it wouldn't be a bad idea to be able to save attachments from
GNUS (current article) to any Org node, via org-attach. Since I use
helm-org-ql to quickly access the headlines of my org documents, it
occurred to me to write this action for helm-org-ql. I share it here in
case someone finds it useful.
Best regards,
Juan Manuel
#+begin_src emacs-lisp
(defun my-helm-org-ql/gnus-save-parts-to-org-attach (marker)
(interactive)
(switch-to-buffer (marker-buffer marker))
(goto-char marker)
(org-show-entry)
(when (not (member "ATTACH" (org-element-property :tags (org-element-at-point))))
(org-toggle-tag "ATTACH"))
;; create attach dir if not exits
(let ((atch-dir (org-attach-dir t))
(art gnus-article-current))
(gnus-summary-save-parts "." atch-dir art)))
(with-eval-after-load 'helm-org-ql
(add-to-list 'helm-org-ql-actions
'("Save attachments" . my-helm-org-ql/gnus-save-parts-to-org-attach) t))
#+end_src
^ permalink raw reply [relevance 9%]
* Re: [BUG] Conflict between org-emphasis and org-latex
@ 2021-09-26 18:29 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-26 18:29 UTC (permalink / raw)
To: Léo Ackermann, Timothy; +Cc: orgmode
Hi Léo and Timothy,
Léo Ackermann writes:
> [...]
> I think that this bug has been introduced recently (I
> never noticed it before)
I don't know if I'm pointing in the right direction, or I am missing
something, but I would say that this is a problem (or consequence) of
`org-emphasis-regexp-components'. According to the docstring, it is a list
with five parts:
("-[:space:]('\"{"
"-[:space:].,:!?;'\")}\\["
"[:space:]"
"." ;; <<====
15)
where part 4, body-regexp, is: "A regexp like "." to match a body
character. Don’t use non-shy groups here, and don’t allow
newline here".
Therefore, the segment "} and {" is fontized here as emphasis
For a LaTeX fragment I think you can do:
(setq org-highlight-latex-and-related 'script)
According to the docstrip:
Non-nil means highlight LaTeX related syntax in the buffer.
When non-nil, the value should be a list containing any of the
following symbols:
‘native’ Highlight LaTeX snippets and environments natively.
‘latex’ Highlight LaTeX snippets and environments.
‘script’ Highlight subscript and superscript.
‘entities’ Highlight entities.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-fstree.el overview over directories (but no comments are possible)
@ 2022-10-30 19:04 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-30 19:04 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> I have a file called bio-hoja4%ftag_EDO Uwe.pdf
>
> I use helm-locate and type %ftag_
> but I receive nothing found see the screenshot.
>
>
> helm-min
>
> And typing %ftag also does not work,
>
> What do I miss?
Ah, sorry, I thought you used helm-locate before. helm-locate depends on
the GNU/Linux 'locate' program. You have to install it. I don't know
what distro you use, but the package is usually called mlocate or
plocate (these are two different implementations of locate). I have
mlocate installed on Arch Linux. According to the Arch wiki:
------------
- mlocate (Merging Locate) is a more secure version of the locate utility,
that only shows files accessible to the user.
- plocate (Posting Locate) is a locate based on posting lists, consuming
mlocates database ahead-of-time and making a much faster (and smaller)
index out of it.
------------
Generally, when you install locate it is automatically configured so
that the database is updated every time you start a session. If you want
to update it in the middle of a session, you must execute the updatedb
command with sudo in the terminal.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-fstree.el overview over directories (but no comments are possible)
@ 2022-10-30 18:17 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-30 18:17 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Hm I played around with filetags and it is quite nice, I think, thanks
> for pointing it out to me.
>
> I would be extremely interested how you use helm-locate in that context,
> and you give me an example, please?
>
> For example I have the following tags added to a specific directory
> bio-hoja4 -- EDO Uwe.tex
> and
> h1A_ECM_n -- analysis1.tex
>
> How would I use helm-locate to search those tags?
At first I used a controlled vocabulary for the tags, setting the
variables filetags-enforce-controlled-vocabulary and
filetags-controlled-vocabulary. But I was getting some false positives.
So it occurred to me to configure this other variable like this:
(setq filetags-delimiter-between-filename-and-tags "%ftag_")
This way, if I start typing in helm-locate %ftag_ I already start
getting more accurate results. Like I said, it's not a panacea, but it
more or less does the trick :-)
BTW, i don't use helm-locate directly but helm-mini with a number of
sources related to buffers, markers, and files:
(setq helm-mini-default-sources '(helm-source-buffers-list
helm-source-recentf
helm-source-buffer-not-found
helm-source-bookmarks
helm-source-bookmark-set
helm-source-locate))
So with a single call to helm-mini I can get information about open
buffers, recent files, bookmarks, and locate.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org-syntax: Intra-word markup
@ 2021-12-02 19:09 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-02 19:09 UTC (permalink / raw)
To: Tom Gillespie; +Cc: orgmode
Tom Gillespie writes:
> I don't mean to be a wet blanket, but the edge cases for
> the current markup syntax are already hard enough to
> implement correctly, to the point where different parts of
> Org mode are inconsistent. Intra-word markup isn't viable
> because there simply isn't any sane way to parse something
> like *hello world*/hrm/oh no*. The other issue is that this will
> degrade parsing performance because almost every
> character could precede the start of a markup section.
>
> I recommend anyone suggesting solutions try to implement
> something that can parse the markup unambiguously with
> lots of nasty test cases. You will likely find that it is impossible
> to consistently tokenize markup, and that you have to hand
> write a whole bunch of heuristics, making Org syntax even
> harder to implement correctly.
>
> Any solution that suggests extending how =/*~+_ can be
> used gets a hard no from me. I could see teaching other
> exporters how to interpret \emph{hello}world, but trying for
> to have any sane behavior for something like
> why *hello*world oh no a wild askterisk*
> is not worth it.
I believe, that emphasis marks are a part of Org that can be very
shocking to new users. I mean, there is a series of behaviors that seem
obvious and trivial in the emphasized text, but that in Org are not
possible out of the box, unless you configure
`org-emphasis-regexp-components'. Three quick examples. This in Org is
not possible out of the box:
#+begin_example
[/emphasis/]
¡/emphasis/!
¿/Emphasis/?
#+end_example
Nor is it possible ---out of the box--- to extend emphasis beyond a
certain number of lines. New users who come from other forms of markup
maybe expect the obvious to be something like:
some-text begin-emphasis whatever-is-in-between end-emphasis more-text
Over time one ends up seeing these things more as a feature than as a
bug :-) But those little inconsistencies make the Org syntax a bit ugly,
IMHO. I can't think of how to improve that, though.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: A simple Lua filter for Pandoc
@ 2022-01-05 17:08 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-05 17:08 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> It seems, lightweight markup is more annoyance than advantage for you.
> Tom posted some thoughts on more rigorous syntax in the following message:
It's generally the opposite: working in Org is a pleasant journey for
me... except when there are dozens of "/" and "*" in a document, and
they placed in 'unhappy' positions. For example, in phonetics the
"/ ... /" notation is used a lot, and there may be cases like:
#+begin_example
/foo/ /bar/ /baz/
#+end_example
In grammar the asterisk is also used a lot, to designate that a term is
not attested or to indicate that it is ungrammatical:
#+begin_example
*foo *bar *baz
#+end_example
And we can even have the combination of both:
#+begin_example
/*foo/ /*bar/ /*baz/
#+end_example
And in certain cases, they are usually expressed in italics. With these
landscapes, it's worth having a few entities rather than working from
pure LaTeX, which is more accurate, but horribly more verbose.
This is a page from a book I typesetted a couple of years ago (when the
pandemic started), entirely from Org:
https://i.imgur.com/f6X7qLs.png
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-22 12:49 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-22 12:49 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode, Ihor Radchenko
Max Nikulin writes:
> Form my point of view it is unnecessary magic. Originally #+latex_header
> is intended for valid LaTeX code
OK, so why not just:
#+latex_header: % NOLANG
?
I think this has in its favor: a) it is simple and obvious to remember;
b) it's a single string, and of course c) it's valid LaTeX code. And it
can be easily controlled from org-latex-guess-babel/polyglossia-language
with a conditional.
Anyway, whatever the choice, I would vote for Org not to load babel or
polyglossia by default, and for the default option of the custom
variable that handles that globally to be nil. For example, I'm in the
group of users that load babel using an external preamble (a .tex or a
.sty file or a 'latex-class'), and frankly I don't want to have to add a
new line to all my documents to prevent Org from reloading babel for me
and return an error on the compilation.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Footnote tooltips (an attempt)
@ 2022-02-22 4:32 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-22 4:32 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 953 bytes --]
Hi all,
I think sometimes it would be nice to have tooltips in the footnote
references, so I can see the contents of each footnote definition,
especially when I'm in a narrowed subtree; so I've tried to write some
code. I have achieved a "semi-automatic" solution. It doesn't work bad
at all, but I'm not entirely convinced either. With a minor mode the
`org-activate-footnote-links' function is overridden, and tooltips content
for all footnotes in the document are added or updated after a couple of
actions when you finish writing or editing a footnote:
`org-edit-src-exit' and `org-mark-ring-goto'. And that's where the
automatic part ends. Beyond that, tooltips must be updated/added by
calling the `my-org-fn-make-tooltips' function.
Here is a short video demo: https://cloud.disroot.org/s/a4gejYc6PSwNWHY
I attach the code of my poor man's footnote tooltips. Of course, any
comment and/or feedback is appreciated.
Best regards,
Juan Manuel
[-- Attachment #2: fn-tooltips.org --]
[-- Type: application/vnd.lotus-organizer, Size: 3405 bytes --]
^ permalink raw reply [relevance 9%]
* Re: [External Email] Re: publishing: no default publishing function, or symbol is not defined
@ 2021-06-19 19:32 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-19 19:32 UTC (permalink / raw)
To: Christopher W. Ryan; +Cc: orgmode
Hi Christopher,
Christopher W. Ryan" via "General discussions about Org-mode. writes:
> I would expect each named entry in an index to appear once, with, if
> necessary, multiple links next to it for all the places that index tag
> occurs in the main document. At least, that's how the indices in books
> work. Can the same be done in org mode?
I'm afraid that in HTML that is not possible. Page numbers are used in
books to refer to an index entry, but on a web site we don't have page
numbers: Where would we apply the links? What I usually do with my web
index is: use first-level entries for the general concept and second or
third level entries for concepts more concrete.
P.ej:
In document A:
#+INDEX: GNU Emacs!external packages!projectile
In document B:
#+INDEX: GNU Emacs!external packages!helm
Links to document A and B go to projectile and Helm
Anyway, I think in this scenario it's better to use tags, but
org-publish doesn't provide tags out of the box. You need to do some
elisp hacking to get something like blog tags in your web site.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [tip] Export to PDF with latexmk 'continuous preview' option
@ 2024-03-05 0:58 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-05 0:58 UTC (permalink / raw)
To: orgmode
A little-known (and sometimes very useful) latexmk option is the -pvc
option. According to the latexmk manual:
[...] The second previewing option is the powerful -pvc option
(mnemonic: "preview continuously"). In this case, latexmk
runs continuously, regularly monitoring all the source files
to see if any have changed. Every time a change is detected,
latexmk runs all the programs necessary to generate a new
version of the document. A good previewer will then
automatically update its display. Thus the user can simply
edit a file and, when the changes are written to disk,
latexmk completely automates the cycle of updating the .dvi
(and/or the .ps and .pdf) file, and refreshing the
previewer's display. It's not quite WYSIWYG, but usefully
close.
In order to use this option from Org, I have defined a simple minor mode
that runs latexmk with the -pvc option and creates a buffer to monitor
the process. Every time the document, or any file involved, is saved,
the PDF is updated. We can define in our `latexmkrc' our favorite
external PDF viewer (Atril, Okular, Evince, etc.). I have this line:
┌────
│ $pdf_previewer = "atril %O %S > /dev/null 2>&1 &";
└────
And here's the code (for documents that are long, complex, or take a
while to export, it may be better to use the asynchronous version of
`org-latex-export-to-latex'):
┌────
│ (defun my-org-compile-latexmk-interactive ()
│ (let* ((tex-file (org-export-output-file-name ".tex")))
│ (start-process-shell-command
│ "latexmk"
│ (format "*%s-latexmk-process*" (file-name-sans-extension tex-file))
│ (concat
│ "latexmk -f -pvc -lualatex -e '$lualatex=q/lualatex %O -shell-escape %S/' "
│ tex-file))))
│
│ (define-minor-mode org-interactive-compile-pdf-mode
│ "TODO"
│ :lighter " OrgInteractivePDF"
│ (if org-interactive-compile-pdf-mode
│ (progn
│ (my-org-compile-latexmk-interactive)
│ (add-hook 'after-save-hook #'org-latex-export-to-latex nil t))
│ (remove-hook 'after-save-hook #'org-latex-export-to-latex t)
│ (when (equal (process-status "latexmk") 'run)
│ (kill-process "latexmk"))))
└────
And a screencast:
<https://cloud.disroot.org/s/ztFfa27kdsnNkGc>
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 9%]
* Re: Line breaks and brackets in LaTeX export
@ 2022-11-01 16:55 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-01 16:55 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: Ihor Radchenko, orgmode
Max Nikulin writes:
> LaTeX verse package require "\\!" as stanza separator to get proper line count,
> so square bracket on the next line is not the only character that may change
> meaning of "\\". So "[*!>" (depending on context) should be handled.
Only when the separation between stanzas is made by means of a blank
line. With the current behavior of verse blocks in the export to LaTeX,
where the separation between stanzas is done by a \vspace, there is no
problem.
When, months ago, I contributed the LaTeX verse numbering patch, I took
this into account, and it didn't seem like the right time to change the
default behavior of the verse block.
I hope to be able to send a new patch soon in the few days (according to
what we discussed in past messages) where the separation by stanzas is
applied by means of a blank line (which is the right thing to do in
LaTeX). I'm rewriting my old code for verse numbering so that a \\! is
automatically added in the last line of each stanza when line numbering
is on.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: ConTeXt exporter makes me happy
@ 2022-02-24 19:58 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-24 19:58 UTC (permalink / raw)
To: juh; +Cc: orgmode
juh writes:
> thanks a lot for org-mode and the ConTeXt exporter.
> https://github.com/Jason-S-Ross/ox-context
>
> With your help, in the last few months I setup a complete authoring and
> publishing environment for my needs with org-mode and ox-context. I
> collect my thoughts with org-roam, outline and write my texts with Emacs
> and org-mode and typeset my books with ConTeXt. Perfect match!
>
> ConTeXt is a wonderful tool to typeset books. It is much more flexible
> than LaTeX and very powerful.
>
> Before ox-context my authoring and publishing setup was a combination of
> Markdown, Pandoc and ConTeXt. It was quite perfect and handsome. The
> only drawback of this setup is the break between my Zettelkasten
> (org-roam) and my publishing tools.
>
> So, I am very happy that ox-context is there and is continually
> improved. The possibility to export to ConTeXt is a good reason to
> learn more facets of org-mode which is quite a big beast.
Although I prefer LaTeX to ConTeXt for my typesetting and publishing
work, I agree that ConTeXt is an excellent tool, and for many users it
can provide a number of advantages over LaTeX. I agree also that Jason
has done a great job with ox-context, and I join in the congratulations.
I recommend LaTeX users, and even users of LaTeX via Org-Mode, to give
ConTeXt a try, if you haven't tried it yet. And of course try
ox-context. One of the historical drawbacks of ConTeXt has always been
its poor documentation, compared to LaTeX's documentation (it's not
really deficient, but what abounds is the documentation at a more
technical level). But luckily there is now an excellent ConTeXt
introductory manual, written by Joaquín Ataz López and with translations
(so far) into English, French, Russian and Serbian:
https://github.com/contextgarden/not-so-short-introduction-to-context
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* A minor mode for inserting things while typing
@ 2021-01-12 22:30 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-12 22:30 UTC (permalink / raw)
To: orgmode
Hi,
I've written a 'lazy' minor mode for inserting things while typing
(without leave the comfort zone of the keyboard) especially when you are
at the end of a paragraph and then you want to insert a block, a list, a
table, a footnote, etc. The idea is: you type ",,," plus one character
-> a white line (with org-return) is inserted -> (depending on the
character typed) something is inserted. For example: ",,,h" inserts a
new heading at the same level; ",,,t", a TODO heading; ",,,-", a list;
",,,1", a numbered list; ",,,k", a check box list; ",,,:", a description
list; ",,,s", a source block; ",,,q", a quote block; ",,,|", a table
(calling org-table-create); ",,,f", a footnote. And so on.
It's a way to insert things that I find more comfortable (in certain
scenarios) than using `org-tempo'.
In case it could be useful to someone, I share it in this GitLab
snippet: https://gitlab.com/-/snippets/2060125
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* "Continuous Integration and TeX with Org-Mode", by Rohit Goswani (TUG 2021)
@ 2021-08-06 10:33 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-06 10:33 UTC (permalink / raw)
To: orgmode
Hi all,
I share here the announcement of this presentation by Rohit Goswani
entitled "Continuous Integration and TeX with Org-Mode", scheduled for
Saturday, 7 Aug, within TUG 2021:
----
Sat, 7 Aug – 10:30 AM | Rohit Goswami Continuous Integration and TeX
with Org-Mode
In this talk I would like to introduce the usage of TeX and templates
along with generating ad-hoc class and style files for working with
orgmode. In particular, I will highlight also the process by which
literate programming practices can be implemented with babel. This
allows for a more native and flexible alternative to vendor locked in
systems like Jupyterlab which rely on JS based inelegant approaches
towards TeX typesetting. Alternative pdf generating backends consuming
TeX like Sphinx will also be covered. Finally, I would like to go into
how to leverage CI methods for TeX workflows augmented with git.
---
More info: https://tug.org/tug2021/sched.html
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Raw Org AST snippets for "impossible" markup
@ 2021-12-08 23:19 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-08 23:19 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> As you have guessed, It is not my choice, it is interface of ox.el and
> org-element.el.
Indeed. Sorry for my haste: it's the consequences of not read the code
carefully :-)
Of course, your orgia-link-procedure could be extended to more org elements.
I can't think of what kind of scenario that might fit in, but as a proof
of concept I find it really stimulating. E.g:
#+begin_src elisp
(org-export-string-as "<orgia:(verse-block () \"Lorem\\nipsum\\ndolor\")>" 'html t)
#+end_src
#+RESULTS:
: <p>
: <p class="verse">
: Lorem<br />
: ipsum<br />
: dolor</p>
: </p>
#+begin_src elisp
(org-export-string-as "<orgia:(quote-block (:attr_latex
(\":environment foreigndisplayquote :options {greek}\"))
\"Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲν
Ἀρταξέρξης, νεώτερος δὲ Κῦρος·\")>" 'latex t)
#+end_src
#+RESULTS:
: \begin{foreigndisplayquote}{greek}
: Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲνἈρταξέρξης, νεώτερος δὲ Κῦρος·
: \end{foreigndisplayquote}
> However if you strongly want to use proper terminology in markup, you
> may try to trade it for +your soul+ compatibility and portability
> issues. The following almost works:
Interesting, thank you.
Yes, it is strange the new line added in `evilatex-emph' ... I have no
idea why that happens.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: http links translated to html : target "_blank"
@ 2021-02-01 11:03 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-01 11:03 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
I think the problem is how the exporter understands the url string.
Note that this:
@@html:<a href="https://www.mpic.de/4747361/risk-calculator" target="_blank">Simulador de riesgo con más detalle</a>@@
[[https://www.mpic.de/4747361/risk-calculator target="_blank"][Simulador de riesgo con más detalle]]
is exported like this:
<p>
<a href="https://www.mpic.de/4747361/risk-calculator" target="_blank">Simulador de riesgo con más detalle</a>
</p>
<p>
<a href="https://www.mpic.de/4747361/risk-calculator%20target=%22_blank%22">Simulador de riesgo con más detalle</a>
</p>
The second link is wrong formatted. A dirty solution could be:
#+BIND: org-export-filter-final-output-functions (correct-target-blank)
#+begin_src emacs-lisp :exports results :results none
(defun correct-target-blank (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "%20target=%22_blank%22\"" "\" target=\"_blank\"" text)))
#+end_src
Best regards,
Juan Manuel
Uwe Brauer <oub@mat.ucm.es> writes:
> Hi
>
> I need to produce a html file, with links opening new tabs (pages) as in
>
> <a href="https://apps.apple.com/es/app/radar-covid/id1520443509" target="_blank">Descarga Directa</a>
>
> However
>
> [[https://www.mpic.de/4747361/risk-calculator target="_blank"][Simulador de riesgo con más detalle]]
>
> Did not work
>
> Any ideas?
>
> Thanks and regards
>
> Uwe Brauer
>
>
^ permalink raw reply [relevance 9%]
* Re: latex block tikz to svg
@ 2022-01-17 16:01 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-17 16:01 UTC (permalink / raw)
To: Edouard Debry; +Cc: orgmode
Hi Edouard,
Edouard Debry writes:
> I would like to find a way to generate svg images from latex src blocks
> (using tikz) which works and is compatible with default orgmode settings
> for latex export (at least does not break it)
>
> Did you experience such issues ? do you have some workings settings and
> examples ? I googled several times "org latex block tikz svg", but it is
> difficult to guess how relevant are the elements found, some of them
> seems quiet outdated. Hence my question on this mailing list
I've done some quick tests with your example block. I don't know if I'm
wrong, but I think the problem is on line 27 of `org-babel-execute:latex':
((string= "svg" extension)
I don't know if this should be considered an Org bug, but it's clear
that if the svg extension is detected in :file, the ':imagemagick yes'
option is ignored, and a type of preamble is generated that fails in
pgfsysdriver when compiling the temp tex document:
\documentclass[preview]{standalone}
\def\pgfsysdriver{pgfsys-tex4ht.def}
If I replace the above line with this conditional:
((and (string= "svg" extension) (not imagemagick))
then the imagemagick option is taken into account: it creates correctly
the pdf and then converts it to svg with 'convert' imagemagick program.
I did have to remove this line though:
#+HEADER: :imoutoptions -geometry 400 :iminoptions -density 600
otherwise, the conversion produced a dark image.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-23 15:53 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-23 15:53 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Kai von Fintel, orgmode
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
Hi Ihor and Kai,
Ihor Radchenko writes:
> Hmm. You are actually right.
> Juan, can you please take a look. It looks like you missed
> "org-latex--format-spec" in the patch. It should use the new
> org-latex-language-alist variable instead.
Attached a new patch to fix (I hope) the org-latex-language-alist issue
in org-latex--format-spec.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Fix-obsolete-variables-for-babel-an.patch --]
[-- Type: text/x-patch, Size: 1554 bytes --]
From 95ce88336f6d2106968250379767ce2fe690fe2c Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 23 Jul 2022 17:42:50 +0200
Subject: [PATCH] lisp/ox-latex.el: Fix obsolete variables for babel and
polyglossia
* (org-latex--format-spec): Use the new variable `org-latex-language-alist'
---
lisp/ox-latex.el | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 6cd751409..ee059d5ce 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1860,10 +1860,12 @@ INFO is a plist used as a communication channel."
(defun org-latex--format-spec (info)
"Create a format-spec for document meta-data.
INFO is a plist used as a communication channel."
- (let ((language (let ((lang (plist-get info :language)))
- (or (cdr (assoc-string lang org-latex-babel-language-alist t))
- (nth 1 (assoc-string lang org-latex-polyglossia-language-alist t))
- lang))))
+ (let ((language (let* ((lang (plist-get info :language))
+ (l (assoc lang org-latex-language-alist)))
+ (cond ((and (consp l) (= (length l) 4))
+ (nth 2 (assoc-string lang org-latex-language-alist t)))
+ ((and (consp l) (< (length l) 4))
+ (nth 1 (assoc-string lang org-latex-language-alist t)))))))
`((?a . ,(org-export-data (plist-get info :author) info))
(?t . ,(org-export-data (plist-get info :title) info))
(?s . ,(org-export-data (plist-get info :subtitle) info))
--
2.37.1
^ permalink raw reply related [relevance 9%]
* Re: how to export red colored TeX to latex
@ 2021-11-30 16:56 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-30 16:56 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode, John Kitchin
Hi,
Uwe Brauer writes:
> Hi
>
> I want to obtain a latex file that contains
>
> \textcolor{red}{$\delta \phi = \frac{2 m}{R}$}
>
>
> However when I add
> \textcolor{red}{$\delta \phi = \frac{2 m}{R}$}
>
> To an org file and export it as Latex, the construct ends up like this
>
>
> \textcolor{red}\{\(\delta \phi = \frac{2 m}{R}\)\}
>
> Which is wrong.
>
> Any ideas how to obtain the correctly exported expression?
Not exactly related, but if it helps, I have defined this custom link
for colored text segments:
(NB: I apply two colors for `:face', because normally I use two themes,
one clear for the day and another dark for the night hours: when my dark
theme is active, apply a background color. But you can simplify that part to
your liking):
(org-link-set-parameters "color"
;; :display 'full
:face (lambda (path) (when path
(if (string= (face-attribute 'default :background) "#282c34")
`(:foreground ,path :background "#F5f5f5")
`(:foreground ,path))))
:export (lambda (path desc format)
(cond
((eq format 'latex)
(concat
"\\textcolor{"
path
"}{" desc "}"))
((eq format 'html)
(format "<span
style=\"color:%s;\">%s</span>"
path desc)))))
The link would then look like this, adapting John's solution using a
LaTeX export snippet:
[[color:red][@@latex:$\delta \phi = \frac{2 m}{R}$@@]]
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-20 21:30 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-20 21:30 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode, Ihor Radchenko
Max Nikulin writes:
>>> On the other hand I would consider adding babel by default without
>>> explicit header. To suppress loading users may add
>>> #+latex_header: % \usepackage{babel}
>> I don't understand this very well. What would happen, then, to users
>> who
>> prefer to use Polyglossia, or those who prefer to explicitly add babel
>> or polyglossia code?
>
> Certainly if polyglossia or explicit babel related commands are
> detected then default babel configuration is not added to preamble.
> The idea is to add babel if a user have not expressed her intentions
> explicitly.
Ah, I see. I think it's a nice idea. I guess a basic babel setup would
be added to preamble. Something like:
#+language: lang
--> \usepackage[lang]{babel}
But I think also users who use custom preamble templates included in
org-latex-classes or those who load the entire preamble via an external
file (a .sty or .tex file) will want to avoid this. Maybe it would be
nice to add a defcustom, with the following values:
- load babel with the value of #+language, when there is no explicit code from babel (default?)
- load polyglossia, idem but for polyglossia
- nil
- any other arbitrary string?
If the user loads babel or polyglossia explicitly, with AUTO and all
that, then the current rules in
org-latex-guess-babel/polyglossia-language would be applied.
WDYT?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-17 22:07 9% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-17 22:07 UTC (permalink / raw)
To: Atlas Cove; +Cc: orgmode
Hi,
Atlas Cove <Atlas48@gmx.com> writes:
> Code-wise, the use of the '\\' symbol is only tentative, as I
> understand that '\' has special meaning elsewhere in org's syntax, (I
> was even going to submit a patch to add two special symbols somewhere
> down the line). '\\' (or whatever symbol is decided on) would cause
> the org parser to concatenate the next line into the outputted
> previous cell, rendering the output of the first example identical to
> the second example.
I agree that what you are commenting on is the great problem of Org Mode
tables. Just a question. If I have understood it correctly, with this
new syntax you propose, should Org understand all the 'concatenated
text'
Very Citrusy! Very \\
nice indeed!
as a single row (and not as multiple rows)? If so that would be
great, since the best way to deal with this kind of tables with a lot of
text in LaTeX is with the tabularx package. For example, I would export
your table like this:
#+begin_src org
,#+LaTeX_Header:\usepackage{tabularx,array}
,#+ATTR_LaTeX: :environment tabularx :align l>{\raggedright\arraybackslash}Xl :width .6\textwidth :center t
| Name | Description | Price |
|--------------+-------------------------------------------------------+-------|
| Orange Juice | Very Citrusy! Very nice indeed! ... and a lot of text | 5.00 |
| Grape Juice | It's like wine, but you can have it all day! | 6.00 |
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* A simple Lua filter for Pandoc
@ 2022-01-04 10:14 9% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-04 10:14 UTC (permalink / raw)
To: orgmode
Hi,
Very often I need to convert docx documents to Org. There are a series
of characters that I prefer to be passed to Org as Org entities and not
literally, so I have written this little filter in Lua for Pandoc. I
share it here in case it could be useful to someone. Of course, the
associative table can be expanded with more replacement cases:
#+begin_src lua :tangle entities.lua
local chars = {["/"] = "\\slash{}", ["*"] = "\\lowast{}", ["<"] = "\\lt{}",
[">"] = "\\gt{}", ["†"] = "\\dagger{}", [utf8.char(0x00A0)] = "\\nbsp{}"}
function Str (elem)
x = elem.text:match 'http[^%s]'
if not x then
for i in pairs(chars) do
elem = pandoc.Str(elem.text:gsub (i, chars[i]))
end
return elem
end
end
#+end_src
And a quick test:
#+begin_src sh :results org
str="/ † * < > http://foo.es "
pandoc -f markdown -t org --lua-filter=entities.lua <<< $str
#+end_src
#+RESULTS:
#+begin_src org
\slash{} \dagger{} \lowast{} \lt{} \gt{} http://foo.es \nbsp{}
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [PATCH] Possibility of using alternative separators in macros
@ 2021-05-15 20:14 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-15 20:14 UTC (permalink / raw)
To: Bastien; +Cc: orgmode, Eric S Fraga
Hi Bastien,
Bastien writes:
> I'll let Eric test and comment, but in the meantime, I'm just
> noticing the patch breaks many tests in master.
>
> If Nicolas thinks this change is good and Eric validate the patch,
> please prepare one with a commit message, updating the tests too.
Ok, if necessary I will prepare an updated version of the patch, with
the updated tests, and with a commit message (a thousand apologies for
my continuous forgetting in commit messages...).
I have noticed certain bugs in my patch, especially within
org-element-macro-parser (a bad regexp and something else). That caused
macros with a single argument to be incorrectly interpreted (and it also
caused an error in one of the tests). If Eric (or someone else) wants
an updated version of the patch I could send it him.
Anyway, I admit that I have become somewhat skeptical about the
usefulness of my patch. Perhaps, as a patch, it is too premature and
perhaps it's better to leave the macros issue, for the moment, as it
is... What do you think?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Should be possible to export list items emphasized by default?
@ 2021-11-17 13:33 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-17 13:33 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Ypo writes:
> /1. Introduction/
>
> It doesn't work as a list item
>
> 1. /Introduction/
>
> It works as a list item but, when exporting, it doesn't export the
> whole item emphasized.
If I have understood correctly, you want to export the label emphasized
as well, not just the item content... It does not make much sense to
emphasize a label within a list by direct formatting: the style of the
labels must be homogeneous and consistent. On the other hand, the style
for a list environment must be modified in LaTeX globally. The easy way
is to use the enumitem package. For example, if you want all labels in
italics:
#+LaTeX_Header: \usepackage{enumitem}
#+ATTR_LaTeX: :options [label=\emph{\arabic*}.]
1. /foo/
2. /bar/
3. /baz/
The :options attribute pass an optional argument to the `enumerate'
environment, with all the options for the environment (a list of comma
separated keyval values):
\begin{enumerate}[label=\emph{\arabic*}.]
\item \emph{foo}
\item \emph{bar}
\item \emph{baz}
\end{enumerate}
See: https://www.ctan.org/pkg/enumitem
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
@ 2021-12-05 11:08 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-05 11:08 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> I view "Org Mode" as a "brand name". Something uniquely identifying Org
> mode and serving as a search term.
Yes, it makes sense.
> Is it your principal position about the title specifically? Do you think
> that just referring to Emacs in the website description is not
> sufficient?
> Note that my suggestion #1 has nothing to do with actual orgmode.org
> front page. Just about how it appears in search results.
Yes, sorry for not explaining myself well: I was also referring to
search results, not the title in the web site...
But the question is: what need is there to remove the reference to Emacs
in the search result? I think the emphasis is necessary. As we say in
spanish, it's like putting the bandage on before the wound. If there are
people who think that Org Mode can 'live' in some way outside of Emacs
(a respectable opinion, but that I do not share, at least 100%), I think
the burden of the work falls on them and not on us, the users of
Emacs-Org-Mode. Anyway it is my simple and subjetive opinion, and it is
not my intention to initiate a controversy with it.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [PATCH] speed commands: error message when a key is not associated with a command
@ 2022-04-30 11:25 9% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-04-30 11:25 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 387 bytes --]
Hi,
If we have speed commands activated and we type (by mistake) a character
not associated with a command, the letter is printed at point. I think a
more appropriate behavior would be:
- key associated with a command: the command is activated
- key not associated with a command: an error message is displayed.
Attached a patch with that modification.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-org-keys.el-error-message-when-speed-command-is.patch --]
[-- Type: text/x-patch, Size: 1489 bytes --]
From fd380f41420aef9bc91baede9d4cd2cb7eadee0a Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 30 Apr 2022 13:00:02 +0200
Subject: [PATCH] lisp/org-keys.el: error message when speed command is not
defined
* (org-speed-command-activate): If a letter is not associated with a
command, an error message is displayed instead of typing the letter.
---
lisp/org-keys.el | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 782ffa871..a850abb4f 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -835,12 +835,14 @@ See `org-speed-commands' for configuring them."
(when (or (and (bolp) (looking-at org-outline-regexp))
(and (functionp org-use-speed-commands)
(funcall org-use-speed-commands)))
- (cdr (assoc keys
- ;; FIXME: don't check `org-speed-commands-user' past 9.6
- (if (boundp 'org-speed-commands-user)
- (append org-speed-commands
- org-speed-commands-user)
- org-speed-commands)))))
+ (let ((defined (cdr (assoc keys
+ ;; FIXME: don't check `org-speed-commands-user' past 9.6
+ (if (boundp 'org-speed-commands-user)
+ (append org-speed-commands
+ org-speed-commands-user)
+ org-speed-commands)))))
+ (if defined defined
+ (error "Speed command not defined: \"h\" for help")))))
\f
;;; Babel speed keys
--
2.36.0
^ permalink raw reply related [relevance 9%]
* Re: [tip] Export subfigures to LaTeX (and HTML)
@ 2020-12-29 15:00 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-29 15:00 UTC (permalink / raw)
To: John Kitchin; +Cc: orgmode
Hello, John,
Thank you very much for the two links.
John Kitchin <jkitchin@andrew.cmu.edu> writes:
> You might look at this
> http://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/
> for another way to do that.
Your idea of adding attributes to Org links is very interesting and
productive. It also shows the great potential that Org links have.
> Check out this alternative approach all together that also uses a
> special block.
>
> http://kitchingroup.cheme.cmu.edu/blog/2016/01/17/Side-by-side-figures-in-org-mode-for-different-export-outputs/
I also find your approach very interesting. What I like the most is
giving LaTeX a "Lisp skin". It is more elegant and legible. I love
(La)TeX and its potential, but I find its code somewhat ugly, often too
verbose. By the way (offtopic), there is a LaTeX package called
lisp-on-TeX that includes a rudimentary Lisp interpreter:
https://www.ctan.org/pkg/lisp-on-tex. It's interesting, and you can do
some things with it, but I think it's an abandoned project. The TeX
ecosystem has moved to Lua with LuaTeX and LuaMetaTeX, but a LispTeX
would have been wonderful! ;-)
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Dealing with wide labels in description environment
@ 2021-01-22 11:20 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-22 11:20 UTC (permalink / raw)
To: Loris Bennett; +Cc: orgmode
Hello,
"Loris Bennett" <loris.bennett@fu-berlin.de> writes:
> I have tried tweaking options such as labelindent and labelwidth in a
> somewhat haphazard manner with, say,
>
> #+attr_latex: :options [labelindent=0pt, labelwidth=10ex]
>
> but most of my attempts seem to have the main effect of just shifting
> the whole list to the right without right-justifying the labels.
The question is more on the side of LaTeX, and the enumitem package
(which you must have loaded for those options. See:
https://www.ctan.org/pkg/enumitem). For the effect you are looking for
you can try this (for horizontal lengths, it is better to use 'em' than
'ex):
#+LATEX_HEADER: \usepackage{enumitem}
#+attr_latex: :options [labelindent=0em,itemindent=0em,align=right,labelwidth=10em,labelsep=.5em,leftmargin=15.5em]
- short label :: this looks fine
- very annoying overly long label :: Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl,
tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis
dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam
tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum
accumsan nisl.
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org-syntax: Intra-word markup
@ 2021-12-02 19:34 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-02 19:34 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Denis Maier, emacs-orgmode, Ihor Radchenko, Timothy
Hi Nicolas and all,
Nicolas Goaziou writes:
> I find zero-with spaces solution much more elegant. It also doesn't
> change current syntax, which is a big advantage.
I agree that zero width spaces work fine as a solution, but I think they
should not be understood as part of the syntax but as a punctual
(temporal?) remedy to certain scenarios. As mentioned before, in LaTeX
zero width spaces can produce unexpected effects and modify the final
form of the text (at least in luatex). I also don't know if it would be
useful to remove all zero width spaces in the export process, because in
some cases the user may want to keep them, as I think Maxim commented in
a previous message.
As for the solution of using complementary marks ("//...//", etc.), I
think it would undermine consistency, as those marks would only be to
fix exceptions.
It's a tricky subject...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved
@ 2022-08-05 17:14 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-05 17:14 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> Likely never variant is ideal. Maybe language should be always in
> :babel and :babel-ini-only should be boolean. I am not sure though
> that it will not make code more complex in other places, so feel free
> to ignore this comment.
What you say makes a lot of sense. Really the only reason why I avoided
doing something like that was rather the economy, so I didn't have to
put things like (two properties instead of one):
:babel xx :babel-ini-only t etc.
It is also expected that babel-ini-only is a 'temporary' property. At
least I would like it to be so.
According to the Babel documentation:
> Babel is moving gradually from the old and fuzzy concept of language
> to the more modern of locale.
Which is precisely what the new ini files are meant for. Now these files
can only be loaded via \babelprovide or by adding provide=* (and some
other variants) to the babel arguments (this last option is not
supported by my patch, for pdfLaTeX compatibility, where ini files don't
work. I imagine that when that transition is complete, there will be a
more inclusive and universal interface in babel.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: A way to avoid unwanted new lines when using paragraph quotes?
@ 2020-12-27 19:17 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-27 19:17 UTC (permalink / raw)
To: Kashyap Chamarthy; +Cc: orgmode
Hello again Kashyap,
Kashyap Chamarthy <kashyap.cv@gmail.com> writes:
> Hmm, that fixes the new line before the "sub bullet under test 3, with
> a quote". However, a new line still remains after the quote ends (and
> before the "Test 4" starts). Is it possible to nuke that too? If
> not, that's okay, I can live with it. :-)
I'd say a vertical space before and after a block quote would be
'typographically' correct. But if you want to eliminate the space after
the block quote, without having to modify it in a general way, it could
be solved with a bit of Elisp, by defining a custom filter so that the
<blockquote> tag would be modified only within a plain list. Thus, with the
configuration that Diego has suggested, everything would be without
vertical space except the space before each block quote:
#+BIND: org-export-filter-plain-list-functions (my-filter-html)
#+begin_src emacs-lisp :exports results :results none
(defun my-filter-html (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "<blockquote>" "<blockquote style=\"margin-bottom:0px\">" text)))
#+end_src
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-mode export to (latex) PDF
@ 2021-07-10 19:24 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-10 19:24 UTC (permalink / raw)
To: Jonathan McHugh; +Cc: orgmode, Jason Ross
Hi Jonathan,
Jonathan McHugh writes:
> I recall there was momentum re exporting to Context from Orgmode, hopefully a solid implementation is available.
It seems that a member of this mailing list, Jason Ross, is working on a
ConTeXt backend for org: https://github.com/Jason-S-Ross/ox-context/
ConTeXt is a TeX format that uses the LuaTeX engine, but the same
results can be achieved using LaTeX format with the LuaLaTeX version.
Of course, LuaTeX, the TeX engine that runs behind ConTeXt and LuaLaTeX,
was born with a clear multilingual "vocation", and it is the natural
evolution of pdfTeX.
Another option for multilingual documents is to use xeTeX engine and
xeLaTeX format.
ConTeXt is very interesting (a more modular approach, and it is not extended by
macro packages like LaTeX, so that the user already has everything inside
almost out of the box). The problem is that it's not as documented as LaTeX.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-->html text between @ should be red.
@ 2022-01-15 20:58 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-15 20:58 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> (add-to-list 'org-export-filter-plain-text-functions 'my-html-red)
>
> How could I remove something from a list?
I think this would work:
(setq org-export-filter-plain-text-functions
(remove 'my-html-red org-export-filter-plain-text-functions))
Anyway, I recommend that you take a look at the documentation on filters
that Timothy pointed you to, as custom filters are tremendously useful
and versatile, and very "surgical". I use them a lot!
You can also apply a filter only in a document, by using the #+bind
keyword and including the function in a non-exportable code block:
#+begin_src emacs-lisp :exports results :results none
(defun my-html-red (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "@\\([^@]*\\)@"
"<span style=\"color:red\">\\1</span>"
text)))
#+end_src
#+bind: org-export-filter-plain-text-functions (my-html-red)
(You need to set org-export-allow-bind-keywords to non-nil)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-18 17:52 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-18 17:52 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim,
Maxim Nikulin writes:
> On 10/04/2021 07:01, Juan Manuel Macías wrote:
>> Nicolas Goaziou writes:
>>> Could you apply the same fix to the `org-verbatim-re' match above, and
>>> provide an appropriate commit message?
>> Done! I've attached the corrected patch. Sorry for the flaws in me
>> previous patch: I'm a bit of a novice at submitting patches...
>
> I have not read yet the following documents to realize what pitfalls
> could be expected due to significant space added to Spanish and Polish
> collation rules in libc.
>
> http://www.unicode.org/reports/tr10/
> Unicode® Technical Standard #10
> Unicode Collation Algorithm
>
> http://www.unicode.org/reports/tr35/tr35-collation.html#CLDR_Collation_Algorithm
> Unicode Technical Standard #35
> Unicode Locale Data Markup Language (LDML)
> Part 5: Collation
>
> In the meanwhile I have realized that org-sort-remove-invisible
> function has rather strange behavior. There are no tests, so I am in
> doubt if the following result is expected and intended (unpatched
> version)
All this research you've done on spaces and collation rules is very
interesting and enlightening.
Certainly, space is important, as the following list in Spanish is
correctly ordered as:
- lo raro
- lo vano
- localidad
However, with the 'unpatched' version of org-sort-remove invisible I get
this result (which is correct) for this list:
- lo bueno
- lo /bueno/
- lo vano
- lo /vano/
And with the patched version, I get this, which is wrong (!):
- lo bueno
- lo vano
- lo /bueno/
- lo /vano/
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
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-fstree.el overview over directories (but no comments are possible)
@ 2022-10-30 12:52 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-30 12:52 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> The only problem is one cannot add comments in the sense when the tree
> is updated everything gets replaced
> as indicated:
>
> ;; - when triggering an update (by pressing "C-c C-c" while in the line mentioned above)
> ;; the COMPLETE REGION BETWEEN "#+BEGIN_FSTREE" AND "#+END_FSTREE" IS REPLACED.
> ;; - speed
>
>
> So I am wondering. Is there any new package or an update I am not aware
> of that would allow adding comments?
Hi Uwe,
I tried this package a long time ago, and I found the problems you
mention. I noticed also that in large directories it took a eternity to
create the Org nodes. The idea of the package is not bad, but I did not
find a practical use for it. I currently have dired-subtree-toggle
installed, which allows expanding and collapsing dired directories, and
assigned these keyboard shortcuts to it:
(with-eval-after-load 'dired
(define-key dired-mode-map (kbd "<tab>") 'dired-subtree-toggle)
(define-key dired-mode-map (kbd "C-<tab>") 'dired-subtree-cycle))
As to whether there is any new package that does the same thing as
org-fstree, AFAIK I don't think so. Out of curiosity, what use case
would you give to such a package?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: content management in emacs
@ 2021-02-27 20:11 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-27 20:11 UTC (permalink / raw)
To: Martin Steffen; +Cc: orgmode
Martin Steffen <msteffen@ifi.uio.no> writes:
> I am not sure about the question. If I send to an email list, it's an
> address in BBDB. So I ``invoke'' BBDB (M-x bbdb) and give it the name of
> the entry (say org-mode). That's analogous to send to a person: If you
> remember the name (or part of the name), you find the entry, send then
> compose an email ("m") on the entry.
There is also helm-bbdb, wich is very useful
(https://github.com/emacs-helm/helm-bbdb). For Gnus I have defined this:
#+begin_src emacs-lisp
(require 'helm-bbdb)
(setq message-completion-alist '(("^\\(Newsgroups\\|Followup-To\\|Posted-To\\|Gcc\\):" . message-expand-group)
("^\\(Resent-\\)?\\(To\\|B?Cc\\):" . helm-bbdb-expand-name)
("^\\(Reply-To\\|From\\|Mail-Followup-To\\|Mail-Copies-To\\):" . helm-bbdb-expand-name)
("^\\(Disposition-Notification-To\\|Return-Receipt-To\\):"
. helm-bbdb-expand-name)))
#+end_src
And to insert an address at point (for example, in Org, in the `mail_to'
property):
#+begin_src emacs-lisp
(defun my-insert-mail-address-helm-bbdb (_candidate)
(save-window-excursion
(helm-bbdb--view-person-action-1 (helm-bbdb--marked-contacts))
(call-interactively 'bbdb-mail-address)
(kill-buffer))
(yank))
(add-to-list 'helm-bbdb-actions '("Insert mail address" . my-insert-mail-address-helm-bbdb))
#+end_src
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
@ 2022-05-30 15:36 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-30 15:36 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Sounds reasonable. However, a more consistent way to handle line numbers
> would be using switches, like what we do in EXAMPLE blocks. See
> org-element-example-block-parser and 12.6 Literal Examples section of
> the manual.
(I didn't remember that I had sent this patch...).
I'll take a look at the function you mention, when I have some time. In
any case, keep in mind that there are some conventions in verse
numbering: the white lines (separation between stanzas) are never
numbered and there is a sequence: 5 (first verse alwais remains
unnumbered) ... 10 ... 15 ..., which can be chosen using the :lines
attribute. :lines t defaults to a sequence of 5 verses. I chose this
syntax to follow the syntax of verse numbering with output to LaTeX
(another patch of mine that is already included in Org. In that case,
the 'verse' LaTeX package is used).
Verse numbering is a special case. In fact, a long time ago I wrote this
package: https://gitlab.com/maciaschain/org-verse-num
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-attach-git don't automatically commit changes
@ 2021-01-30 13:38 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-30 13:38 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi Ihor,
Ihor Radchenko <yantar92@gmail.com> writes:
> Note that org "sees" changes in the attachment dir only when you use
> M-x org-attach command to manage the attachments. Directly changing the
> attachment directory will not be noticed. You can force org-mode to
> check for changes in attachment dir by running "C-c C-a z".
Thanks for the explanation. It seems that I had misinterpreted
what the manual said :-)
Anyway, in my case, it still doesn't work (?). I think it's for a path
problem. In `org-attach-git-commit' there is this variable:
#+begin_src emacs-lisp
;; ...
(let* ((dir (expand-file-name org-attach-id-dir))
;; ...
#+end_src
The default value of `org-attach-id-dir' is "data/", and if I evaluate
`(expand-file-name org-attach-id-dir)' on my current node, it returns a
wrong path to the attached folder. `org-attach-sync' only works for me
if I set in `org-attach-git-commit' the variable like this:
#+begin_src emacs-lisp
;; ...
(let* ((dir (org-attach-dir)) ;; <====
;; ...
#+end_src
In that case, it does recognize the path correctly. Again, I don't
know if I'm missing something...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org-syntax: Intra-word markup
@ 2022-02-02 20:01 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-02-02 20:01 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> ATTR_X attributes are supported for links as well, see
> info "(org) Links in HTML export"
> https://orgmode.org/manual/Links-in-HTML-export.html
> However it is rather verbose, may have problems with LaTeX, and I am
> unsure if they can be accessed from export link handlers
Yes, I know. I use a lot in my blogs constructions of this type:
#+ATTR_HTML: :target _blank
some link...
But, as far as I know, its use is line-oriented. I mean, you can't use
multiple ATTR_X constructs inside a paragraph and for different links
inside the paragraph.
As for links and their multiple possible or future uses (I say *uses*
and never *abuses*: it's a tool, it's there to be used, and it works
great), of course I see them more as a resource ---and quite powerful
and versatile, by the way. --- that a matter of syntax. But the thing is
that for me Org is, in addition to a syntax, above all a set of
coherently assembled resources to prepare my documents and take my
notes, organize my work and a lot of other things.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Way to mark contents of an Org special block as verbatim?
@ 2022-01-06 18:27 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-06 18:27 UTC (permalink / raw)
To: Kaushal Modi; +Cc: orgmode
Hi Kaushal,
Kaushal Modi writes:
> I would like to treat that block /like/ how Org treats the latex
> environment blocks, but it needs to be a special block as
> begin_katex/end_katex here is special and it could be a different
> equation rendering backend for another user.
>
> So is that a header switch or arg that can be passed on to this
> special block that enables the verbatim mode (prevent Org from
> replacing the Org entities, do the sub/superscript expansion, etc.)?
I think one possibility would be using a parse tree export filter:
#+BIND: org-export-filter-parse-tree-functions (katex-verbatim)
#+begin_src emacs-lisp :exports results :results none
(defun katex-verbatim (tree backend info)
(when (org-export-derived-backend-p backend 'latex)
(org-element-map tree 'special-block
(lambda (block)
(when (equal "katex" (org-element-property :type block))
(let ((cont (org-element-interpret-data (org-element-contents block)))
(create-export-snippet ;; idea from Nicolas Goaziou
(lambda (v)
(org-element-create 'export-snippet (list :back-end "latex" :value v)))))
(apply #'org-element-set-contents
block
(list (funcall create-export-snippet cont))))))
info)
tree))
#+end_src
#+begin_katex
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_katex
==>
\begin{katex}
E = -J \sum_{i=1}^N s_i s_{i+1}
\end{katex}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: LaTeX export: grffile is a stub package
@ 2021-09-27 17:00 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-27 17:00 UTC (permalink / raw)
To: meedstrom; +Cc: orgmode
Hi,
meedstrom@teknik.io writes:
> According to https://ctan.org/pkg/grffile, since 2019-11-08, grffile
> is a stub that just loads graphicx, part of texlive-latex-graphics,
> part of texlive-base. My system (Guix) doesn't have a package for
> grffile, so I can't generate a PDF, which is silly because it's a stub
> anyway.
>
> Suggest fixing by removing \usepackage{grffile} in LaTeX export.
>
> A caveat: some distributions seem to still package an old TeXLive full
> distribution, going by Guix which provides a three-gigabyte "texlive"
> package from 2019-04-10. I'm not sure what sort of deprecation time we
> allow.
grffile is a deprecated LaTeX package, but it is included in TeX live
2021 (Arch). The Arch version of TeXlive is identical to the official
version (except that it does not include the documentation, which must
be installed using an AUR package). My recommendation: unless you are in
Arch or one of its derivatives, it is better to always install *the
official and lastest version* of TeX live (with its own installer and
its own package manager); the versions included in the repositories of
many distros (except for Arch and very few others) are usually outdated
or incomplete, and it is better to avoid them. The current version of
TeXlive is TeXlive 2021. There is, by tradition, a version per year and
in each one many things are modified and quite bugs fixed.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [tip] Export and open a PDF in Android via Termux
@ 2022-05-15 11:54 9% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-15 11:54 UTC (permalink / raw)
To: orgmode
Hi all,
I have recently installed TeX live on Android inside Termux:
$ pkg install texlive-installer
(https://wiki.termux.com/wiki/TeX_Live)
And I've managed to open a PDF exported from Org using an external
android viewer (mupdf, downloaded from f-droid). The Termux command is
termux-open. You need to add:
(setq org-file-apps
'((auto-mode . emacs)
(directory . emacs)
("\\.mm\\'" . default)
("\\.x?html?\\'" . default)
("\\.pdf\\'" . "termux-open %s")))
It is necessary also to uncomment the line 'allow-external-apps = true' in '~/.termux/termux.properties'.
And to open the PDF from AUCTeX:
(setq TeX-view-program-list '(("termux" "termux-open %o")))
(setq TeX-view-program-selection
'(((output-dvi has-no-display-manager)
"dvi2tty")
((output-dvi style-pstricks)
"dvips and gv")
(output-dvi "xdvi")
(output-pdf "termux")
(output-html "xdg-open")))
A screencast: https://imgur.com/a/iBvwDTo
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: watch YT videos through in Emacs [Was: Interest in an Org video meetup?]
@ 2022-10-12 10:22 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-12 10:22 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Quiliro Ordóñez, emacs-orgmode
Ihor Radchenko writes:
> Quiliro Ordóñez <quiliro@riseup.net> writes:
>
>> Hola Juan Manuel.
>>
>>> There is the YouTube option, which I imagine no one would like (me
>>> neither). The only thing in its favor is that Invidious can be used to
>>> watch the videos. BTW, I watch YT videos through Invidious in Emacs,
>>> with the Ytel package and EMMS/MPV.
>>
>> Nice. Is there a guide to do this specificly?
>
> I simply use
>
> #+begin_src bash :tangle ~/.local/bin/qutebrowser-call.sh :shebang #!/bin/bash
> URL="$1"
>
> if echo "$URL" | grep "youtube.com"; then
> # URL="$(echo "$URL" | sed -r 's/\\(www\\)?youtube\.com/invidious.namazso.eu/')"
> if [[ ! -z $(echo "$URL" | grep "/watch") ]]; then
> mpv $URL && exit;
> fi
> fi
>
> if echo "$URL" | grep "ted.com/talks"; then
> mpv $URL && exit;
> fi
>
> # if echo "$URL" | grep "reddit.com"; then
> # URL="$(echo "$URL" | sed -rE 's/www\.reddit\.com/libredd.it/')"
> # fi
>
> if echo "$URL" | grep "bilibili.com"; then
> mpv $URL && exit;
> fi
>
> grep "$URL" ~/.data/web-mirror/sources/* >/dev/null 2>&1 &&\
> ARCHIVE_DIR="$(echo "$URL" | archivebox-cmd list 2>/dev/null | tail -n1 | cut -d' ' -f1 | sed -r 's|/data|~/.data/web-mirror|')"
>
> if [[ ! -z "$ARCHIVE_DIR" ]]; then
> [[ -f "${ARCHIVE_DIR}/singlefile.html" ]] && URL="${ARCHIVE_DIR}/singlefile.html";
> fi
>
> #from https://github.com/qutebrowser/qutebrowser/blob/master/scripts/open_url_in_instance.sh
> _url="$URL"
> _command=":later 4000 :jump-mark last-position"
>
> qutebrowser "${_command}" ":spawn -u untrack-url -r -O ${_url}"
>
> #+end_src
>
> and my mpv is configured to use youtube-dl.
In this short video I show an example of my procedure to watch youtube
videos without leaving Emacs:
https://cloud.disroot.org/s/X3cfi2orT38CPyM
I use:
1. Helm-google-suggest (set to use duckduckgo)
2. Ytel (based on elfeed). With a few hacks that I have added, in order
to:
- Display thumbnails in the searches.
- Watch the video at point (via invidious) with EMMS/MPV,
configured with yt-dlp, which is a fork of youtube-dl that works
much better.
- Download the video at point with yt-dlp (full video or only audio)
- Create a bookmark of the video with org-capture
More info on my blog in Spanish (if anyone is interested, I can translate it):
https://gnutas.juanmanuelmacias.com/ytel_invidious.html
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org-syntax: Intra-word markup
@ 2021-12-02 23:24 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-02 23:24 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Nicolas Goaziou writes:
> I'm suggesting to remove zero-width spaces contiguous to emphasis
> markers only. Therefore LaTeX process would npot see them. Other zero
> width spaces, e.g., inserted by user, are kept. AFAICT, the two last
> points you mention are not relevant with my proposal.
>
> Besides, they already part of the syntax, in some way. So that ship has
> sailed long ago.
I understand that it is too late to change certain things, but that is
not an impediment for me to continue to think that using the character
U+200B as a part (at least /de facto/) of the syntax is still shocking
and weird.
On the other hand, what was expected in Org would have been to have the
emphasis marks and at the same time have a universal escape character
for those emphasis marks. In the same way as I can write in markdown:
*foo* AND \*foo\*. In Org we have the emphasis marks but not the escape
character. That was probably the cause of many issues that are being
discussed here. But that means also entering the realm of assumptions.
Still, I wanted to leave an opinion on this question in particular.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [off topic] List all non-latin characters in a buffer
@ 2022-08-16 15:19 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-16 15:19 UTC (permalink / raw)
To: orgmode
Sorry for the offtopic, but I thought this homemade function I wrote
some time ago for my work might perhaps be useful to some Orgers. When
executed in a buffer, the `list-non-latin-chars' function opens a window
displaying a list of all the non (basic) Latin characters present in
that document. Each item in the list contains the character, its Unicode
canonical name, and its hexadecimal code. For example:
殿 CJK IDEOGRAPH-6BBF #6bbf
Also, each item is a button (created with button.el). If the button
is activated, there are currently two options: a: execute occur on that
character in the document; b : execute describe-char on that character.
By default, the characters displayed in the list correspond to any
Unicode block other than basic-latin. Which means that the zero width
space character is included, a very famous character in this mailing
list :-)
And here is the code (lexical binding is required). Of course, feedback
welcome.
Best regards,
Juan Manuel
#+begin_src emacs-lisp
(setq ext-chars-actions-list '((?a "Occur"
(lambda (buf char)
(interactive)
(with-current-buffer buf
(occur char))))
(?b "Describe char"
(lambda (buf char)
(interactive)
(with-current-buffer buf
(save-excursion
(goto-char (point-min))
(when (re-search-forward char nil t)
(describe-char (- (point) 1)))))))))
(defun ext-chars-choose-action (buf char)
(let ((opt (read-char-choice (concat "Escoger acción >>\n\n"
(mapconcat (lambda (item)
(format "%c: %s"
(car item) (nth 1 item)))
ext-chars-actions-list " --- "))
(mapcar #'car ext-chars-actions-list))))
(apply (nth 2 (assoc opt ext-chars-actions-list))
(list buf char))))
(defvar ext-chars-list nil)
(defun list-non-latin-chars ()
(interactive)
(setq ext-chars-list nil)
(let ((buf (buffer-name)))
(save-excursion
(goto-char (point-min))
(while
(re-search-forward "\\([^\u0000-\u007F]\\)" nil t)
(add-to-list 'ext-chars-list (format "%s" (match-string 1))))
(setq ext-chars-list-final
(mapcar (lambda (char)
(let
((char-name (get-char-code-property (string-to-char char) 'name))
;; convert to hexadecimal
(char-code (format "#%x" (string-to-char char))))
(setq char (format "%s\s\s%s\s\s%s" char char-name char-code))))
ext-chars-list))
(let ((temp-buf (format "*non latin chars in %s*" buf)))
(when (get-buffer temp-buf)
(kill-buffer temp-buf))
(get-buffer-create temp-buf)
(set-buffer temp-buf)
;; necessary for Arabic, Hebrew, etc.
(setq bidi-display-reordering nil)
;; insert buttons list
(mapc (lambda (el)
(let ((char (when (string-match "^\\(.\\)\s" el)
(match-string 1 el))))
(insert-button (format "%s" el)
'action (lambda (x)
(interactive)
(ext-chars-choose-action buf char)))
(insert "\n\n")))
ext-chars-list-final)
(pop-to-buffer temp-buf)
(goto-char (point-min))
(view-mode)))))
#+end_src
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
@ 2021-12-05 9:16 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-05 9:16 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> The website title is "Org mode for Emacs", repelling users who _do
> not want_ to use Org inside Emacs. Maybe we can do better? Something
> with less accent on Emacs like "Org mode: your life in plain text"
I am not at all in favor of separating the 'Org Mode' name from 'GNU Emacs'.
In any case, regardless of my opinion, I see here two problems:
1. "Org mode: your life in plain text". The word "mode" remains orphan:
mode of what? It is clear that it is an Emacs mode, therefore it doesn't
make much sense to hide Emacs and then suggest it.
2. One possibility: "Org: your life in plain text". But here what
remains orphaned is "Org", too generic name. Unless "Org Mode" is a
lexicalized construct, without reference to any emacs mode.
(In any case, I would be extremely saddened if the reference to GNU Emacs
disappears in the title, just to please a minority).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [BUG] Footnotes in section titles
@ 2024-01-24 15:41 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-24 15:41 UTC (permalink / raw)
To: Colin Baxter
Cc: Max Nikulin, Eric Anderson, ihor Timothy, Ihor Radchenko, orgmode
Colin Baxter writes:
> >> 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.
>
> Indeed, but many journals *require* footnotes in titles, especially for
> affiliation, email, etc.
Notes on article titles (and even on the author name) are a slightly
different case from notes on section titles. In LaTeX there is the
"\thanks" command, which inserts footnotes for title and author,
numbered with fnsymbol. For example:
...
\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. 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...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Fallback fonts in LaTeX export for non latin scripts
@ 2023-09-07 12:04 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-07 12:04 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> May we explicitly set the needed font around language environments?
>
> Something like
>
> \setfontforrussian
> \selectlanguage{russian}
> ....
>
> \setfontforbulgarian
> \selectlanguage{bulgarian}
> ....
There's no need. With \babelfont you can associate a font with a
language (declared with both the classic syntax and \babelprovide. And
when you use \selectlanguage, \foreignlanguage or any other babel
command or environment to switch languages, the associated font is
activated for that language. For example:
\babelprovide[import]{russian}
\babelprovide[import]{bulgarian}
\babelfont[russian]{rm}[]{Old Standard}
\babelfont[bulgarian]{rm}[]{Freeserif}
and then:
\selectlanguage{russian}
...
\selectlanguage{bulgarian}
...
\babelprovide supports several properties. Adding the onchar=ids
fonts/letters property equates language and script, and everything in
that script is associated with a font. This would only make sense to use
when there is only one language in the document that has that script, as
we discussed before. In case like russian/bulgarian, the source of the
last babelprovide is overwritten for all cases where that script
appears.
>
>> In any case (to organize myself mentally) I thought that it could be
>> done on two levels:
>>
>> - Level 0: The fonts associated with each script are loaded (from a
>> defcustom list) if luatex is the current engine. And low-level code is
>> generated in Lua with the luaotfload.add_fallback function. That code
>> can be in a Lua file or directly within the preamble, enclosed in the
>> \directlua primitive (mode=harf means that HarfBuzz is used as otf
>> rendering):
>> ...
>
> Sounds reasonable.
>
>> - Level 1: The user can load language properties and associate fonts
>> with each language using Babel's high-level code (via keywords in Org,
>> as we have commented in previous messages). Here you can also modify
>> the default fonts (also, as we mentioned before): main, mono, sans and
>> math. If the language is declared with an asterisk (for example:
>> russian*) the onchar=etc property will be included in the preamble,
>> and it would not be necessary to switch to russian explicitly. It is
>> assumed that in this scenario the only language with Cyrillic script
>> would be Russian. For language swithcing, in the rest of the cases,
>> some babel command would have to be used using @@latex:@@, special
>> blocks, etc. When Org already has its own language switching
>> mechanism, this would be used instead. Wdyt?
>
> I am not sure if I like "russian*" idea. May you explain a bit more
> about how onchar works? What if language characters are intersecting,
> and not using exactly the same char sets?
Basically, it's like I said above. According to the Babel Manual:
#+begin_quote
onchar= ids | fonts | letters
This option is much like an ‘event’ called when a character belonging to
the script of this locale is found (as its name implies, it acts on
characters, not on spaces). There are currently two ‘actions’, which can
be used at the same time (separated by a space): with ids the \language
and the \localeid are set to the values of this locale; with fonts, the
fonts are changed to those of this locale (as set with \babelfont).
Characters can be added or modified with \babelcharproperty.
[...] Option letters restricts the ‘actions’ to letters, in the TEX
sense (i. e., with catcode 11). Digits and punctuation are then
considered part of current locale (as set by a selector). This option is
useful when the main script is non-Latin and there is a secondary one
whose script is Latin.
#+end_quote
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-21 15:45 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-21 15:45 UTC (permalink / raw)
To: orgmode
Hi all,
Maxim Nikulin writes:
> I think, new variant should be committed even it does not fix Juan's
> case. He have not confirmed the fix yet.
Sorry, I have been busy with other matters and had lost the thread of
the discussion. I'm catching up on the messages...
I have tried the Nicolas' patch (latest version) and I see that the
items with emphasis are already ordered well. However, it seems that the
problem with identical items with or without emphasis still persists:
which items should go before and in what order? For example, in the
following list I get:
- /a/
- *a*
- a
- *b*
- /b/
- b
- /v/
- *v*
- v
Anyway, I think it is a minor problem (I can't think of many
scenarios in real life where this problem is relevant). In a more
realistic case, the result is correct:
- lo /bueno/
- lo bueno
- lo /vano/
- lo vano
...
- /a/
- b
- /v/
- *z*
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
@ 2021-04-05 21:36 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-05 21:36 UTC (permalink / raw)
To: Dr. Arne Babenhauserheide; +Cc: orgmode
Hi Arne,
Dr. Arne Babenhauserheide writes:
> Except if there is any feature you want to use that doesn’t work under
> LuaTeX.
>
> pdfpages for example says that it only supports pdflatex and vtex.
pdfpages works perfectly with both LuaTeX and XeTeX. I've been using it
in LuaLaTeX for quite some time, by the way. Please read the first page
on the package documentation:
http://mirrors.ctan.org/macros/latex/contrib/pdfpages/pdfpages.pdf
Currently There are very few things that will not work under luatex, for
now (certain microtype properties, like letter tracking, and little
else). In fact, the current trend is the opposite: many new packages
that are emerging do not work under pdftex. The natural evolution of the
TeX ecosystem is heading to LuaTeX, although it is normal for the TeX
community to be cautious about backward compatibility and still mantain
pdfTeX. But the present is already LuaTeX, clearly. The future, who
knows...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* An attempt to convert Elfeed entries (with parameters) to Org trees
@ 2021-05-31 10:40 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-31 10:40 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
Hi all,
I like to keep up to date with new LaTeX packages that are being
uploaded to CTAN and I'm subscribed to the CTAN news feed. I always use
Elfeed to check my subscriptions, but it occurred to me to write a
function (with org-map-entries) to be able to pass Elfeed entries (with
certain parameters) to Org trees.
For example, something like:
* New on CTAN
:PROPERTIES:
:ELFEED: @6-months-ago +TeX New on CTAN
:END:
Or, for /This Month in Org/:
* /This Month in Org/
:PROPERTIES:
:ELFEED: @3-months-ago +tmio
:END:
And then run `my-org/insert-entries-elfeed'.
If anyone wants to try it, I attach an Org document with the code, which
is very preliminary, not too fancy and quite improvable. Feedback
welcome! :-)
Best regards,
Juan Manuel
[-- Attachment #2: elfeed-to-org.org --]
[-- Type: application/vnd.lotus-organizer, Size: 3719 bytes --]
^ permalink raw reply [relevance 9%]
* citation-style-language: new LaTeX package in TL 2022
@ 2022-05-12 10:44 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-12 10:44 UTC (permalink / raw)
To: orgmode
Hi all,
TeX Live 2022 includes a new LaTeX package for citations,
'citation-style-language', written by Zeping Lee. According to the
package description:
"[...] The citation-style-language package is aimed to provide another
reference formatting method for LaTeX that utilizes the CSL styles. It
contains a citation processor implemented in pure Lua (citeproc-lua)
which reads bibliographic metadata and performs sorting and formatting
on both citations and bibliography according to the selected CSL style.
A LaTeX package (citation-style-language.sty) is provided to communicate
with the processor."
https://ctan.org/pkg/citation-style-language
https://github.com/zepinglee/citeproc-lua
I'm not sufficiently familiar (at the moment) with org-cite, but I share
the news here in case this new LaTeX package could have some kind of use
for org-cite export options.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org-attach for a directory
@ 2022-06-08 10:32 9% ` Juan Manuel Macías
[not found] ` <CAPHku6O3RojzhaSu3d2pWfnE8x7N_9WAfjCupHyKcxNyD-i=ew@mail.gmail.com>
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-08 10:32 UTC (permalink / raw)
To: Cletip Cletip; +Cc: orgmode
Hi,
Cletip Cletip writes:
> My question is in the object : can we attach a directory to a heading?
> If yes, how, if not, why. Can we solve the problem?
I have in my init the following modification to the org-attach-attach
function so that I can copy a directory. I have replaced the line
((eq method 'cp) (copy-file file attach-file))
with this:
((eq method 'cp) (if (file-directory-p file)
(copy-directory file attach-file)
(copy-file file attach-file)))
You can override the old function with advice-add:
(advice-add 'org-attach-attach :override 'my-new-org-attach-attach)
> Subsidiary question:
> Can we use org-attach as a filesystem?
> Thanks in advance for your future answers
Can you please elaborate more? In my case, I use org-attach almost as a
replacement for my folder system (ie org nodes have come to replace
directories, and many nodes have a folder attached); I access the nodes
via org-ql/helm-org-ql (https://github.com/alphapapa/org-ql). It's very
productive.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: A callygraphy notebook environment
@ 2022-01-30 21:23 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-30 21:23 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe,
Thanks for testing the document.
Uwe Brauer writes:
> Interesting I like them all. I converted your org file to latex and run
> it with lualatex but the font used there does not correspond to all the
> three screenshots.
The default font for the environment 'mynotebook" is qtmerryscript
(shown in the third screenshot, if I remember correctly). I chose that
one because it is included in TeX live 2021.
> Now I am not really acquainted with lualatex but with xelatex, I
> converted QTMerryScript.otf to ttf and run it with xelatex. Nice.
But with XelaTeX the 'mynotebook' environment will not work, since it uses
a function in Lua to generate the grids in a notebook way.
> What are the other otf fonts you are using for these screenshots?
The document itself includes some links to download the other typefaces. Look
in the non-exportable section, named 'Conf', where it says "The different options
for the environment...". Anyway, I paste it here too:
- Vladimir Script :: https://fontzone.net/font-details/vladimir-script
- Anke Calligraphic :: https://fontzone.net/font-details/anke-calligraphic-fg
- Studio Script :: https://fontzone.net/download/studioscriptctt
(The third font was not in the screenshots).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Nested macros and fontification
@ 2021-03-15 17:10 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-15 17:10 UTC (permalink / raw)
To: orgmode
Hi,
I make heavy use of replacement macros, and often my Org documents are
full of nested macros (in the 'LaTeX way') throughout the text. The
problem is that `org-fontify-macros' breaks the macro fontification when
it is a nested construction.
I've found a simple high level solution that consists in ensuring that the
macros have a look identical to normal text (in my theme):
(set-face-attribute org-macro nil :bold nil :foreground black)
And then I only highlight the macro boundaries with `highlight-regexp'. I
think that this gives me a more legible and consistent text, without
that 'rainbow effect' that many themes apply to macros. I share a couple
of samples, in case this little solution is helpful to someone who also
uses a lot of (nested) replacement macros:
https://imgur.com/a/fSPHH0w
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: export dispatch → change the default "Contents" string
@ 2021-10-01 16:35 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-01 16:35 UTC (permalink / raw)
To: Jean-Christophe Helary; +Cc: orgmode
Hi, jean-Christophe,
Jean-Christophe Helary writes:
> What is the parameter to change the default "Contents" ToC string when exporting to PDF ?
If I'm not wrong, I think there is no native Org way to change the
default string for LaTeX literals. But if you use babel (the LaTeX
package), you can add this command:
#+LaTeX_Header: \addto{\captionsenglish}{\renewcommand\contentsname{foo}}
That's the old way of doing it, and it still works. The latest Babel
versions also incorporate this other variant:
\setlocalecaption{language-name}{caption-name}{string}
for example:
\setlocalecaption{english}{contents}{Table of Contents}
NB: I strongly recommend using babel always for LaTeX, in any of its
flavors (pdfLaTeX, XeLaTeX, LuaLaTeX), instead of polyglossia, which is
a very buggy package. This package came up when babel didn't support
XeTeX and LuaTeX, years ago, but now it doesn't sense to use it.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [DISCUSSION] Re-design of inlinetasks
@ 2023-08-25 17:58 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-25 17:58 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
> 1. Inlinetasks should be exported as "boxes" - something similar to
> margin or inline notes
> - Can be used as a memo TODO in draft publication printout
> - As Samuel suggested, inlinetasks could be a basis of review
> comments - like what GDocs/Office provides in margin "chat"
I think inlinetasks may also have a use for those sections that are not
"nested". In typography they are usually called "anonymous sections" and
they are separated by some symbol (asterisks, dinkus[1], etc.). They
behave like a true section, except that they are not headed by titles or
level numbers. I think Org's support for these types of sections would
be useful and novel, since there is (as far as I know) nothing similar
in other lightweight markup languages. Anonymous sections can be useful
not only in print or PDF texts but also on web pages.
https://en.wikipedia.org/wiki/Dinkus
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [patch] Add two new header args to LaTeX block
@ 2024-02-10 1:58 9% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10 1:58 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
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:
#+begin_src latex :pdf-process '("lualatex -shell-escape -interaction nonstopmode -output-directory %o %f")
\textbf{hello world}
#+end_src
- `: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:
#+begin_src latex :full-to-pdf yes
\documentclass{article}
\begin{document}
\textbf{hello world}
\end{document}
#+end_src
I think both arguments can have many practical uses. For example, to
compile separately and load multiple subdocuments, with different
preambles:
#+NAME: doc1
#+begin_src org :exports none :results latex
,#+include: some-document.org
#+end_src
#+begin_src latex :noweb yes :results silent file :file file.pdf :full-to-pdf yes
\documentclass{article}
\usepackage[spanish]{babel}
\usepackage{fontspec}
\setmainfont{Vollkorn}
\begin{document}
<<doc1()>>
\end{document}
#+end_src
#+latex: \includepdf{file.pdf}
Or even to evaluate ConTeXt code within a LaTeX block:
#+begin_src latex :full-to-pdf yes :results raw file :file file.pdf :pdf-process '("cd %o && context %f")
\starttext
\startsection[title={Testing ConTeXt}]
Lorem ipsum dolor.
\stopsection
\stoptext
#+end_src
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-ob-latex.el-Add-two-new-header-args-to-LaTeX-bl.patch --]
[-- Type: text/x-patch, Size: 2148 bytes --]
From fe1b40e2b22e2c668440bea13feda0ab7923bdd8 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): `:pdf-process' allows modifying the value
of `org-latex-pdf-process' in a specific block. The `:full-to-pdf'
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 | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index acb83228b..118d81338 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -162,6 +162,9 @@ 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)))
+ (pdf-process (cdr (assq :pdf-process params)))
+ (org-latex-pdf-process (if pdf-process pdf-process org-latex-pdf-process))
+ (full-to-pdf (cdr (assq :full-to-pdf 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 +190,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) full-to-pdf)
+ (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 9%]
* Convert a Lisp expression to a tree diagram
@ 2022-06-30 14:19 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-30 14:19 UTC (permalink / raw)
To: orgmode
Hi all,
Sorry for the slight offtopic. I'd like to be able to graphically
convert (from a src block) a Lisp expression to a tree diagram, similar
to trees used in (human) syntax and grammar, especially generative
grammar (this is a web app for generating such trees:
http://www.ironcreek.net/syntaxtree/). I think I can try some LaTeX hack
using the 'forest' package (here's a related thread with pros and cons:
https://tex.stackexchange.com/questions/140812/drawing-a-lisp-expression-as-a-tree),
but I was wondering if anyone knows of any more emacs/elisp/org friendly
packages/solutions. Some time ago I saw an Emacs package that could
convert a Elisp expression into an ascii text tree diagram, but I can't
remember its name and I can't find it anywhere...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-02 18:15 9% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-02 18:15 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
Hi all,
I have noticed that a couple of (spurious?) spaces in a `format'
expression of `org-sort-remove-invisible' is causing `org-sort-list' not
to sort correctly (alphabetically) the items that contain emphasis marks
in a plain list. I propose this very simple patch to fix that problem.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-sort-remove-invisible_remove_spaces.patch --]
[-- Type: text/x-patch, Size: 494 bytes --]
diff --git a/lisp/org.el b/lisp/org.el
index 04da1afcd..d10cc2f5c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8114,7 +8114,7 @@ Optional argument WITH-CASE means sort case-sensitively."
(replace-regexp-in-string
org-verbatim-re (lambda (m) (format "%s " (match-string 4 m)))
(replace-regexp-in-string
- org-emph-re (lambda (m) (format " %s " (match-string 4 m)))
+ org-emph-re (lambda (m) (format "%s" (match-string 4 m)))
(org-link-display-format s)
t t) t t))
^ permalink raw reply related [relevance 9%]
* Re: Smart quotes not working correctly with single quotes
@ 2021-05-28 17:02 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-28 17:02 UTC (permalink / raw)
To: Andreas Gösele; +Cc: orgmode
Hi Andreas,
A quick fix (for LaTeX, odt and HTML), if you want to use second-level
quotes as first-level quotes in parts of your document, could be to
define a filter. You must put these quotes as ´ ... ´ (for example):
#+LANGUAGE: de
#+OPTIONS: ':t
#+BIND: org-export-filter-final-output-functions (single-quote-filter)
#+begin_src emacs-lisp :exports results :results none
(defun single-quote-filter (text backend info)
(cond ((or (org-export-derived-backend-p backend 'html)
(org-export-derived-backend-p backend 'odt))
(replace-regexp-in-string "´\\([[:graph:]]+\\)" "‚\\1"
(replace-regexp-in-string "\\([[:graph:]]+\\)´" "\\1‘"
text)))
((org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string "´\\([[:graph:]]+\\)" "‚\\\\glq{}\\1"
(replace-regexp-in-string "\\([[:graph:]]+\\)´" "\\1\\\\grq{}"
text)))))
#+end_src
It's a ´test´. "Please".
Best regards,
Juan Manuel
Andreas Gösele writes:
> Thanks Juan Manuel!
>
> Your suggestion works for LaTeX, but I need the other formats too. I
> tried to convert the LaTeX document with pandoc, tex4h and latex2html to
> odt and html but none of them produces the correct output.
>
> So I'm wondering whether there is any way to make org export to
> recognize single quotes also outside from double quote. It should be
> possible as inner quotes is not the only use of simple quotes.
>
> Thanks again!
>
> Andreas
>
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Hi Andreas,
>>
>> I don't know if this is a bug, but I would say that in principle it's
>> the expected result. Single quotes are understood here as inner quotes
>> or second-level quotation marks, therefore they are only activated
>> nested in text with first level quotes: " ... '...' ... "
>>
>> lorem "ipsum 'dolor sit' amet"
>>
>> For LaTeX output, however, the csquotes package is a more powerful
>> option to control the correct quotation marks for each language. For
>> example:
>>
>> #+LaTeX_Header: \usepackage[german,english]{babel}
>> #+LaTeX_Header: \usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
>> #+LaTeX_Header: \MakeOuterQuote{"}
>> #+LaTeX_Header: \MakeInnerQuote{´}
>>
>> #+LaTeX: \selectlanguage{german}\EnableQuotes
>> It's a ´test´. "Please".
>>
>> lorem "ipsum ´dolor´ sit" amet
>>
>> Best regards,
>>
>> Juan Manuel
>>
>> Andreas Gösele writes:
>>
>>> Hi,
>>>
>>> even using "smart quotes", single quotes are not correctly exported into
>>> html, odt or latex.
>>>
>>> I have as document:
>>>
>>> | #+LANGUAGE: de
>>> | #+OPTIONS: ':t
>>> | #+OPTIONS: toc:nil
>>> | It's a 'test'. "Please".
>>>
>>> If I export it to html I get:
>>>
>>> | It’s a ’test’. „Please“.
>>>
>>> I should get:
>>>
>>> | It’s a ‚test‘. „Please“.
>>>
>>> If I export to latex I get:
>>>
>>> | It's a 'test'. "`Please"'.
>>>
>>> I should get:
>>>
>>> | It's a \glq{}test\grq{}. "`Please"'.
>>>
>>> If I export to odt I get:
>>>
>>> | It’s a ’test’. „Please“.
>>>
>>> I should get:
>>>
>>> | It’s a ‚test‘. „Please“.
>>>
>>> (The odt example outputs use utf8, I hope it gets transmitted.)
>>>
>>> So in all three cases apostrophes and double quotes are correctly
>>> exported, but not single quotes. Similar problem if I use "#+LANGUAGE:
>>> en".
>>>
>>> I have org-mode 9.3 with emacs 27.1.
>>>
>>> What could I do to get single quotes to be exported correctly?
>>>
>>> Thanks a lot!
>>>
>>> Andreas
>>>
^ permalink raw reply [relevance 9%]
* Re: Missing the second '}'
@ 2022-01-24 16:46 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-24 16:46 UTC (permalink / raw)
To: Sharon Kimble; +Cc: orgmode
Hi Sharon,
Sharon Kimble writes:
> Hi folks.
>
> In a document that I'm compiling I seem to have failed to close the '{'
> and '}', and the second one isn't in the document. If I write '\label{}'
> then it succeeds, but at a couple of places in the document this show
> '\label{'.
>
> How can I find where I've failed to close the brackets please, so that I
> can then achieve normality please?
Is this an Org document that you are exporting to LaTeX? If there is a
compile error, you can usually see it at the end of the *Org PDF LaTeX
Output* buffer. If it is a badly closed command, it is usually a
"Runaway argument?" warning, and the compiler indicates the problematic
line, which you should look for in the *.tex document. Sometimes it's
not easy to find the problem. The fastest way is to compile the *.tex
document directly with LaTeX and review the log file. It also usually
works to raise the position of \end{document} in the document. There
will come a point where it stops giving errors, and then the problem
will be easily located in the paragraph after \end{document}.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-attach-git don't automatically commit changes
@ 2021-01-31 10:29 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-31 10:29 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi Ihor,
Ihor Radchenko <yantar92@gmail.com> writes:
> Does it mean that your attachment folder is set in :DIR: property?
No, my attachment folder is build using :ID: property. For example, in
my heading:
* Test
:PROPERTIES:
:ID: d0e690e2-2ecd-4224-891a-b91257db5389
:END:
And if I evaluate `org-attach-dir' here, it returns the correct path:
#+begin_src emacs-lisp
(org-attach-dir)
#+end_src
#+RESULTS:
: /home/juanmanuel/Documentos/docs-compartidos/org/data/d0/e690e2-2ecd-4224-891a-b91257db5389
But if I evaluate this, I get an 'incomplete' path:
#+begin_src emacs-lisp
(expand-file-name org-attach-id-dir)
#+end_src
#+RESULTS:
: /home/juanmanuel/Documentos/docs-compartidos/org/data/
So if I replace `(expand-file-name org-attach-id-dir)' with
`(org-attach-dir)' in `(org-attach-git-commit)' [line 7, the `dir'
variable], it works fine when I run 'C-c C-a z'.
Best regards
Juan Manuel
>
> I suspect that it is a leftover from the major changes in org-attach
> when :DIR: property was introduced. The org-attach-git presumes that all
> the attachments in current file are stored in sub-directories located
> inside org-attach-id-dir, which is no longer guaranteed. In fact, the
> existing approach to treat all the attachments to all headings in
> current file as files in a single git repo cannot be used. I can see two
> possible fixes:
> 1. Treat each attachment dir as individual git repo (breaking change for
> those who are using :ID: property to build the attachment dirs)
> 2. Treat attachment dirs defined by :DIR: property individually and
> leave the :ID:-defined attachments as they were treated before
> (inconsistent).
>
> I am in favour of the first approach since I do not like the idea of
> keeping all the attachments in the whole file in a single git repo.
> I think feedback from other is needed to decide what we need to do here.
>
> P.S. Marking this as a bug.
>
> Best,
> Ihor
>
^ permalink raw reply [relevance 9%]
* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
@ 2024-01-21 17:47 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-21 17:47 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List
Pedro Andres Aranda Gutierrez writes:
> +#+begin_example
> +,#+latex_class_options: [greek,spanish,oneside]
> +,#+language: es
> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> +,#+latex_header: \usepackage{alphabeta} % to support greek script
> +#+end_example
I think this example doesn't take advantage of the AUTO facility, which
is what the section is about. Btw, maybe it would be nice to extend ''AUTO'' to
latex_class_options and \PassOptionsToPackage? Something like:
#+latex_class_options: [greek,AUTO,oneside]
#+language: es
...
However, I would only find the \PassOptionsToPackage command useful in
classes that already load babel with a main language. From Org, using
just pdfTeX, I think it would be simpler:
#+language: es
#+latex_header: \usepackage[greek,AUTO]{babel}
#+latex_header: \usepackage{alphabeta} % to support greek script
or this variant, using babelprovide and an INI file:
#+language: es
#+latex_header: \usepackage[greek]{babel}
#+latex_header: \babelprovide[import,main]{AUTO}
#+latex_header: \usepackage{alphabeta}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Line breaks and brackets in LaTeX export
@ 2022-10-21 19:32 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-10-21 19:32 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Max Nikulin writes:
> My impression is that tabularray has an ambitious goal to replace all
> current table packages. I have no idea if other packages will adopt
> similar approach with regexp-based parsing instead of usual expanding
> of TeX commands.
Yes, that's the impression I have too. Tabularray certainly solves a lot
of traditional LaTeX table problems (unfortunately not the one we're
dealing with). Time will tell if it also creates other new problems. In
any case, it brings a lot of flexibility to a part of LaTeX, tables,
that has always suffered from a certain constriction. We'll see what
happens. LaTeX is becoming very complex and now several layers coexist,
since the jump to LaTeX 3 is going to be gradual. On the other hand, I
don't know if the latex core developers have a cleaner \\ command in
their roadmap, without those absurd current problems (and that LaTeX has
been carrying for almost 40 years).
> I do not like necessity to add \NewTableCommand\empty{} to documents
> somehow (only if tabularray is loaded). I do not have an idea better
> than \\[0pt] and an optimizing filter to remove [0pt] in almost all
> cases.
I totally agree.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [PATCH] org.el: use only link descriptions in indirect buffer names
@ 2021-05-22 14:12 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-22 14:12 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
Hi,
When a heading contains a link with a description,
`org-tree-to-indirect-buffer' can produce in the name of the indirect
buffer strings like this:
"streaming.org-[[url-media:http://192.168.1.36:8888/Radiohead%20-%20Studio%20Discography/OK%20Computer%20%281997%29/recurse.m3u][Radiohead
-- OK Computer (1997)]]-1"
I would like to propose the attached patch, so that only the link
description is used in the indirect buffer name:
"streaming.org-Radiohead -- OK Computer (1997)-1"
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-el-use-only-link-descriptions-in-indirect-buffer.patch --]
[-- Type: text/x-patch, Size: 1228 bytes --]
From b859f45abaa94e546e625b7b8c9f47ed64d6b4b4 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 22 May 2021 15:33:15 +0200
Subject: [PATCH] org.el: use only link descriptions in indirect buffer names
* lisp/org.el (org-tree-to-indirect-buffer): If the variable `heading'
contains a link with a description, it is replaced by the description string.
---
lisp/org.el | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 1bd9e02eb..ca87cac67 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6895,8 +6895,13 @@ frame is not changed."
(while (> (setq level (org-outline-level)) arg)
(org-up-heading-safe)))
(setq beg (point)
- heading (org-get-heading 'no-tags))
+ heading (replace-regexp-in-string
+ org-link-bracket-re
+ (lambda (x)
+ (pcase (match-string 2 x)
+ (`nil (match-string 1 x))
+ ((pred stringp) (match-string 2 x))))
+ (org-get-heading 'no-tags)))
(org-end-of-subtree t t)
(when (org-at-heading-p) (backward-char 1))
(setq end (point)))
--
2.26.0
^ permalink raw reply related [relevance 9%]
* [tip for EXWM users] An alternative method for isolate trees
@ 2021-03-01 12:55 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-01 12:55 UTC (permalink / raw)
To: orgmode
Hi,
Since EXWM uses Emacs frames as virtual desktops, I have written this
alternative method of `org-tree-to-indirect-buffer', which I share here.
With this method I can have several isolated trees, with their own name,
and access them quickly (with helm-buffer-list, for example):
#+begin_src emacs-lisp
(defun my-goto-buffer-regexp (regexp)
(dolist (buffer (buffer-list))
(let ((name (buffer-name buffer)))
(when (and name (not (string-equal name ""))
(string-match regexp name))
(switch-to-buffer buffer)))))
(defun my-org-tree-to-indirect-buffer ()
(interactive)
(let ((buf (buffer-name))
(ind-buf (replace-regexp-in-string "\\[.+\\]" "" (nth 4 (org-heading-components))))
(org-indirect-buffer-display 'new-frame))
(org-tree-to-indirect-buffer)
(my-goto-buffer-regexp ind-buf)
(rename-buffer (concat buf "::" ind-buf))))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-13 19:08 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-13 19:08 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi, Maxim,
Thanks for clearing things up. So it seems obvious that the root
of the problem is in the locales and the collation rules.
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...
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).
Best regards,
Juan Manuel
Maxim Nikulin writes:
> I could reproduce such result but I am in doubt if it is a reason to
> merge the patch. I believe, the following behavior is almost expected
>
> list.org:
> - v
> - /v/
> - /a/
> - a
>
> LC_COLLATE=C.UTF-8 LC_ALL= LANGUAGE= \
> emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
> list.org
>
> (org-sort-list t ?a)
>
> - /a/
> - /v/
> - a
> - v
>
> LC_COLLATE=en_US.UTF-8 LC_ALL= LANGUAGE= \
> emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
> list.org
>
> (org-sort-list t ?a)
>
> - /a/
> - a
> - /v/
> - v
>
> Collation rules depend on language. The question is if emphasized
> variant should be sorted first.
>
> P.S. The thread is broken. Some new messages do not have proper
> In-Reply-To header. Original question was not referenced in the
> message with patch as well:
> https://orgmode.org/list/87blbac0k0.fsf@posteo.net/
^ permalink raw reply [relevance 9%]
* Re: Orgdown: negative feedback & attempt of a root-cause analysis
@ 2021-12-01 3:28 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-01 3:28 UTC (permalink / raw)
To: Tom Gillespie; +Cc: orgmode
Tom Gillespie writes:
> Karl,
> The exact naming of a thing is nearly always the most contentious
> step in trying to promulgate it. In my own field we can easily get all
> parties to agree on a definition, but they refuse to budge on a name.
> As others have said, I wouldn't worry about kibitizing over the name.
>
> I would however worry about the larger negative reaction. From my
> perspective I think the issue is that there are many efforts working
> toward a formalized specification for Org syntax and Org mode
> functionality, and some of those stakeholders who have invested
> significant effort may feel blindsided by a public declaration
> announcing Orgdown because they were not consulted and not
> made aware that you were working on it.
>
> I appreciate the amount of work that you have put in, I have devoted
> hundreds of hours to working on an alternate implementation of org
> in Racket that uses a formal ebfn in hopes that others will be able
> to use it as a guide and as a way to talk formally about how Org
> parsers and implementations should behave.
>
> It would thus be easy for me to say that your approach has put the
> cart before the horse, because there are countless nuances in the
> specification for Org syntax which must be addressed before any
> levels of org compliance can be specified, otherwise the behavior
> between levels will be inconsistent.
>
> If I were to say this, it would not be fair to you at all. The ideas
> and motivation for Orgdown are vital and important. You have put
> in enormous thought and effort, all because you care about Org
> and want to see it succeed.
>
> The issue is that any shared specification for Org syntax is
> fundamentally about how to coordinate as a community.
> The way that Orgdown was presented to the community feels
> (to me) like it is being imposed top down or coming from an
> individual source, not from an open and visible community
> process (the subject of your original email reads as a declaration
> in english, and thus can be quite off putting, though I know that
> was not the intention).
>
> I personally haven't bothered with promulgation because I think
> that we are not technically ready as a community to approach
> outreach to other developers in a way that we can succeed.
>
> The good news is that all of this can co-exist if we want it to,
> but we need to be clear about our objectives as a community.
>
> To me these objectives are as follows (and I would love
> to hear from others about additional or alternate objectives).
>
> 1. To never fracture Org syntax so as to avoid the nightmare
> of markdown flavors. (This means being able to say clearly
> as a community that a parser is out of compliance and that
> it is up to the user to fix their files. The ruby org parser used
> by Github is a major issue here.)
> 2. To provide a clear specification for what graceful degradation
> looks like when parsing Org syntax if a parser does not support
> some portion of that syntax (e.g. should property drawer lines
> be excluded or rendered as plain text?).
> 3. Provide a solid basis on which further formal specification
> can be built. (My interests in particular are around providing
> consistent semantics for org-babel blocks across languages
> so that babel implementations can clearly communicate what
> runtime features they support.)
>
> The approach for Orgdown can absolutely meet all three of
> these objectives, however in its current form Orgdown1 is not
> sufficiently well specified to avoid fracturing the syntax.
> This is because Org syntax is extremely complex (even the
> elisp implementation of Org mode is internally inconsistent)
> and there are edge cases where behavior will diverge if parsing
> of even the simplest elements is not fully specified.
>
> There are many ways to remedy this, however they require
> a more formal approach. A number of us are working to build
> technical foundations for such a formal approach, but I do not
> think that any of those projects are ready to be used to
> specify discrete levels of Org syntax parsing compliance.
>
> If I may, I would suggest that an Orgdown0 is something that
> could be well specified, but it would avoid parsing of markup
> altogether and only deal with the major element types. Parsing
> paragraphs and all the org objects is not something that can
> be done piecemeal. There are too many interactions between
> different parts of the syntax, and in some cases the existing
> specification desperately needs to be revisited due to the
> complexity that it induces or because it is underspecified.
> Of course this would make Orgdown0 fairly useless as a
> replacement for markdown, but at least it would be a start.
Everything you comment here seems very sensible to me.
Anyway I have to say that, in my case, the name 'orgdown' is not the
issue, but the underlying idea under the naming, whatever the name is.
IMHO, reduce Org to a markup language or, to put it somewhat
metaphorically, distill Org into a workable markup language outside Org
itself and GNU Emacs, is a task that seems impossible to me. Or at least
(for not being so radical), quite difficult. And, on the other hand,
what would be the point of doing that? I think Org and Markdown are the
antipodes, they are like water and oil, although they share certain
purposes. Just to make my current opinion clear.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [ann] org-font-spec-preview (preview fonts and test open type features)
@ 2022-01-16 16:42 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-16 16:42 UTC (permalink / raw)
To: orgmode
Hi,
I've polished some raw ideas that I shared here a few days ago, and I
have written this little package:
https://gitlab.com/maciaschain/org-font-spec-preview
org-font-spec-preview allows you to preview arbitrary text strings in a
chosen font (or generate a complete specimen) as well as test opentype
features in real time. The preview is done in a temporary buffer, by
executing org-latex-preview, and must be compiled with LuaTeX, since
LuaTeX allows to load fonts that are not installed in the system.
Two user commands are provided:
- ofsp-system-font: Run ido and choose the candidate font from a list of
fonts installed on the system;
- ofsp-dired-font: Preview a font file in Dired.
Feedback welcome!
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* A callygraphy notebook environment
@ 2022-01-30 12:32 9% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-30 12:32 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 785 bytes --]
Hi all,
This is more related to LaTeX than Org, but I'm sharing it here in case
anyone is interested. For a work I'm doing I've written a LaTeX
environment that tries to mimic the look of a calligraphy notebook. By
default it uses the qtmerryscript font, included in TeX live, but this
can be changed to any other calligraphic-style font. It works only with
LuaTeX, since it uses a function in Lua to add the grids.
An screenshots:
https://i.imgur.com/tgrgaWM.png
https://i.imgur.com/AIolze2.png
https://i.imgur.com/v2Mzyx5.png
To use it in Org, a special block would be ideal. For example:
#+ATTR_LaTeX: :options [fontfeature={Color=pen},fontsize=\large]
#+begin_mynotebook
Some text...
#+end_mynotebook
I am attaching an Org document to test it.
Best regards,
Juan Manuel
[-- Attachment #2: notebook.org --]
[-- Type: application/vnd.lotus-organizer, Size: 3824 bytes --]
^ permalink raw reply [relevance 9%]
* Displaying verse numbers within a verse block
@ 2020-12-20 21:37 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-20 21:37 UTC (permalink / raw)
To: orgmode
Hi,
One of the many, many things where I use Org Mode is my Spanish translation of Homer's
Odyssey (work in progress). To avoid getting lost inside each Book, I wrote this little
code that helps me navigate through the verses, displaying in the margin (within a verse
block) the verse numbers in sequence of 5 (not counting the empty lines), or allowing
me to jump to a certain verse number.
I've uploaded the code to GitLab in case it could be useful to anyone who also has to work
with long runs of verses (hundreds, thousands...). Of course, this is something I wrote for
my own work, and I'm not a professional programmer either, so the code can be improved for
sure ;-)
https://gitlab.com/maciaschain/org-verse-num
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: "Orgdown", the new name for the syntax of Org-mode
@ 2021-11-29 12:18 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-29 12:18 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: orgmode
Marcin Borkowski writes:
> Quite the contrary. The amount of confusion between TeX (engine)/TeX
> (language)/TeX (distro)/TeX-aware text editor/LaTeX (whatever) among
> novice/casual users has always been terrible.
It's natural when those novice/casual users approach something that is
new to them, but nothing invincible when they want to learn. The "TeX"
ecosystem is not trivial, but I think that all, or almost all of us,
understand each other when things like 'TeX/LaTeX code', 'TeX engine',
'LaTeX format', etc. are said. If the TeX language were somewhat
self-contained and widely used outside of TeX, I would see OK that the
language had its own name. But, since the TeX language is something that
almost only TeX understands (roughly said), I think the economy wins
here (IMHO). I don't see how we could improve everything by having half
a dozen more exotic names.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**
@ 2022-01-25 17:30 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-25 17:30 UTC (permalink / raw)
To: Vincent Belaïche; +Cc: orgmode
Hi Vincent,
Vincent Belaïche writes:
> My conlcusion is that for what I am after, an evolution of org-mode
> would be preferable, maybe I contribute something someday, so that
> writing one of the following would make it:
>
> ~--my-option=~\relax{}/option value/
> ~--my-option=~@@:@@/option value/
> \left~--my-option=\right~/option value/
> \left~--my-option=\right~\left/option value\right/
> ~--my-option=~\left/option value\right/
Considering that Org's emphasis marks are not compromised by contact
with a single quote, I come up with this somewhat dirty solution: you
can use some kind of dummy mark (e.g. two single quotes: '') and put it
between the two emphasis parts. It would then be removed by a filter.
Something like this:
#+BIND: org-export-filter-final-output-functions (my-filter)
#+begin_src emacs-lisp :exports results :results none
(defun my-filter (text backend info)
(replace-regexp-in-string "''" "" text))
#+end_src
~some-cli-option=~''/some cli argument/
== LaTeX ==>
\texttt{some-cli-option=}\emph{some cli argument}
The solution is tricky and temporary, but at least it's not as
text-invasive as other options.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
@ 2022-06-15 10:30 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-15 10:30 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> The original proposal by Eric Schulte:
> https://list.orgmode.org/4BFFEE4F.5010608@ccbr.umn.edu/
>>>> Maybe we should allow either exporting just the headlines of the
>>>> org-mode file or exporting the entire org-mode file -- possibly after an
>>>> ASCII export -- this would have the effect of prefixing every line in
>>>> the org-mode file behind a comment *except* for the tangled source-code
>>>> blocks.
>
> Clearly, the "possible after an ASCII export" dropped somewhere in the
> middle.
I see... Thanks for the clarification! So it seems that the current
behavior of ':comments org' is no more than a fluke, rather than
intentional. One possibility that occurs to me, instead of adding a new
value to ':comments', would be to 'return' ASCII export for the
:comments org value, and leave it that way by default. And add an
option, of course, for recover the old value. It could be done from
org-babel-process-comment-text, and then redo some lines in
org-babel-tangle-single-block, as we discussed in the other mail. I
think it would be cleaner that way, but I don't know if this would be
too groundbreaking...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* A dictionary made in Org Mode
@ 2021-06-18 12:11 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-18 12:11 UTC (permalink / raw)
To: orgmode
Hi,
I would like to share here my latest work. It has recently been
published in Spain and I think it's the first dictionary made entirely
using Org Mode ;-) I have taken care of its production and its editorial
design:
Diccionario Hispánico de la Tradición Clásica
(Hispanic Dictionary of Classical Tradition)
ISBN: 978-84-18093-93-7
828 pages
Org-publish has been especially useful for its production. Soon I will
write a detailed article in Spanish about the making off. If anyone here
was interested I can try to translate the article into English.
A few samples of the content:
https://cloud.disroot.org/s/tBpMQP6afssY37p
And this short video shows a quick overview of the files involved and
the final compilation, before printing all the work:
https://vimeo.com/538137630
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
@ 2024-01-20 15:41 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-20 15:41 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Max Nikulin
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> Paragraph\\
>>> @@latex:[foo]@@
>>
>> But since in both cases it is literal LaTeX code, the correct thing
>> would be for the user to be in charge of adding the curly braces to the
>> square brackets. I mean in such scenario it is LaTeX code, not Org.
>
> Not really. Because we do not give guarantees about the details of LaTeX
> export, we should try hard to not break things that users may put into
> literal export snippets.
>
>> Anyway, in both examples it does not make sense for LaTeX to end a
>> paragraph with the \\ macro, which is why we commented in previous
>> messages in the thread. The \\ macro is only used in horizontal mode;
>> this macro does not add a new paragraph but rather a forced line break
>> within the paragraph.
>
> In the example with @@latex:[foo]@@, \\ is not at the end of a paragraph
> - it is inside paragraph.
What I mean is that literal LaTeX code is LaTeX code, despite the
redundancy. IMHO, Org's only duty in that case is to export such literal
code as valid LaTeX code, but Org "does not know" what that literal code
consists of. The user who enters the literal LaTeX code is the one who
has the duty to add the necessary elements to that code so that it is
compiled correctly by LaTeX. Let's look at this as a territorial
question:
Scenario A:
@@LaTeX:\libebreak@@ [ipsum] ==> the problem is in Org territory
Scenario B:
lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [patch] Add two new header args to LaTeX block
@ 2024-02-11 20:01 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-11 20:01 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Got it.
> Although, it is confusing to have different formats of :process
> value depending on :file extension.
Indeed. For that reason I changed the original name I gave from
":pdf-process" to simply ":process". IMHO this function has a tremendous
problem: two methods coexist to convert a PDF compiled with LaTeX to an
image: the method with :imagemagick and the method without :imagemagick,
although this can also use imagemagick, which in itself is a first mess.
I don't know if this state of affairs is clear to the user...
The method without :imagemagick, furthermore, is the only one that
depends on a different process (leaving aside the case of conversion to
html, where another process is used).
The method with :imagemagick is, like the rest, more "transparent" (it is
the one I use, and I think many users prefer it):
TeX file --> compilation --> PDF --> conversion --> image file
The method without :imagemagick, which depends on the value of
org-preview-latex-default-process could be schematized like this:
TeX file --> {compilation + PDF + conversion + params.} --> image file
That is, the compilation and conversion processes along with the
parameters are included in the same pack.
> It would make things easier for users if
> :results file :file foo.png :process '("lualatex -interaction nonstopmode
> -output-directory %o %f")
>
> worked as expected, automatically overriding :latex-compiler value in
> let-bound `org-preview-latex-process-alist'.
I think that can cause certain drawbacks. Suppose a user has dvipng
as the value of org-preview-latex-default-process. If he/she puts
":process '(luatex etc ...)"
he/she will not be able to create the image because dvipng has the
value of ":image-converter" as the dvipng program, which, to put it
briefly and without going into details, would not work well with LuaTeX.
It is the problem of the same pack that I mentioned before. That's why I
think the lesser evil would be to allow the user to control the
necessary parameters at will, if the output file is an image file and
":imagemagick" is not present. Anyway, see what I say below.
>> 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)?
>
> I agree that it should be corrected.
> 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.
Another possibility is to clarify the names a little more (for the user):
:image-conv [possible values: default, imagemagick (= :imagemagick 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 9%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
@ 2023-08-07 17:23 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-07 17:23 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> Rationale for this patch: the treatment of blank lines in
>> `org-latex-verse-block' is inconsistent with the syntax of the `verse'
>> environment, both the one that includes LaTeX and the one provided by
>> the `verse' package as a replacement for the former.
>> ...
>> So, after this patch:
>>
>> • Any blank line before and/or after the content is removed;
>>
>> • One or more blank lines between stanzas are exported as a single blank
>> line, leaving the previous final verse without the linebreak mark
>> `\\';
>>
>> • When verse numbering is enabled via the `:lines' attribute (for the
>> `verse' package), the last verses of each stanza are marked with
>> `\\!', according to the verse package syntax (this was not necessary
>> with the previous behavior).
>
> I see nothing that would prevent merging this patch.
> However, I believe that removing blank lines before/after content is
> something we may want to do in other built-in backends as well. WDYT?
I think you're right. My impression is that the blank lines before/after
content is not a desired feature, but rather a consequence of
substituting line breaks to create the space between stanzas. I think
the space before/after is better removed because it doesn't make sense
and adds unnecessary direct formatting[1]. Maybe it could be changed to
`(org-trim contents t) in all cases, like in this patch?
[1] However, the horizontal 'verbatim' space that can be added before
each line/verse seems like a great feature to me, since verses can also
be indented arbitrarily. This block it's a gem, and it has some really
cool features, not just to quote poetry.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
@ 2022-01-24 12:09 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-24 12:09 UTC (permalink / raw)
To: Vincent Belaïche; +Cc: orgmode
Hi Vincent,
Vincent Belaïche writes:
> Hello,
>
> Sorry to dig out this almost 8 year old discussion, but after looking
> into the git HEAD Org Mode manual (v9.5 or so) (info "(org) Emphasis and
> Monospace") node, and after looking into the mail archive I could not
> find any answer to this question: how to switch style within a word.
>
> I would like to put something like this in an OrgMode document:
>
> ~--some-cli-option=~/some cli argument/
>
> where the intent is that « --some-cli-option= » would be monospaced, and
> « some cli argument » would be italicized, and as you know this does not
> work this way.
>
> Vincent.
It seems that this topic is already a classic :-) The supported solution
for intra-word emphases is to introduce a zero width space (U+200B), for
example:
~--some-cli-option=~[zero-width space]/some cli argument/
I don't really like this solution, but at least it works. If you export
to LaTeX, you may want to remove the space using a filter, as in some
(few) cases it can alter the LaTeX result.
The other realistic possibility is to use macros:
{{{mono(--some-cli-option=)}}}{{{emph(some cli argument)}}}
That is, more or less, the state of art. By the nature of its syntax,
emphasis between words is not possible in Org.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-table with different conventions: decimals
@ 2022-07-18 23:02 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-18 23:02 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Now if I want to switch to the convention used in Germany (that might be
> relevant if I want to export it later to csv, but this is a different
> topic) does work in a strange way, any comments? [...]
Hi, Uwe,
If you only need to export to LaTeX you can load the siunitx package,
which not only fits the decimals perfectly in a table but you can also
define a value for the decimal sign that will be seen in the PDF.
It has a small drawback. Columns with numeric value (S) cannot contain
anything other than numbers. If you want to add an arbitrary text string
in one of those columns you must enclose that string in {}. That is, on
the org side it would be @@latex:{foo}@@
You can try this with your example:
#+LaTeX_Header: \usepackage{siunitx}
#+LaTeX_Header: \sisetup{detect-all}
#+LaTeX_Header: \sisetup{output-decimal-marker = {,}}
#+ATTR_LaTeX: :align SSS
| 3.5 | 4.2 | 7.7 |
#+TBLFM: $3=$1+$2
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [DISCUSSION] Re-design of inlinetasks
@ 2023-08-26 14:21 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-26 14:21 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>> 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.
>> ... 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.
>
> Do you mean section in LaTeX sense or in Org sense?
In Org sense, I think. If an author adds an 'anonymous' break (through
some customary symbol) and continues writing, the content that follows
belongs (for Org) to the current section. By using an inlenitask, you
can have control over the inlinetask content, for any purpose, for
example with some export filter, etc.
On the other hand, for my own writing I usually use this:
#+begin_src emacs-lisp
(defun my-org-latex-format-inlinetask-default-function
(todo _todo-type priority title tags contents _info)
(if (string-match-p "anonsec" title)
(concat
"\n\\begin{anonsection}\n"
(org-string-nw-p contents)
"\n\\end{anonsection}\n")
(org-string-nw-p contents)))
(defun mi-org-odt-format-inlinetask-default-function
(todo todo-type priority name tags contents)
(if (string-match-p "anonsec" name)
(concat
contents
"<text:p text:style-name=\"OrgCenter\">* * *</text:p>")))
#+end_src
And for LaTeX I have defined this:
#+begin_src latex
\newcommand\dinkus{\mbox{\textasteriskcentered\space\textasteriskcentered\space\textasteriskcentered}}
\newcommand\anonsectionmark{\dinkus}
%% require the needspace package
\newcommand\anonsectionbreak{%
\nopagebreak[4]
\bigskip%
{\centering
\anonsectionmark\par}
\Needspace*{2\bigskipamount}
\bigskip}
\newenvironment{anonsection}{%
\anonsectionbreak%
}
{%
\par}
#+end_src
>> 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:
>> ...
>> https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering
>>
>> https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks
>
> This one I know. But it can work fine with normal headings, because such
> texts are nothing but a sequence of "scenes" - nothing "inline" when we
> have one scene, interrupted by other, then coming back to the first one.
Actually, I think any anonymous text break or sectioning can be
accomplished using Org headings and some trickery to ignore the heading on
export, but I think inlinetasks lends itself quite well to this
constructions and others I've seen discussed in this thread. In general,
for any 'piece' (section = something that is sectioned) of text that
needs to be separated in some way from the main text, without a
hierarchy of levels, inlinetasks are a great, versatile and simple tool
(IMHO).
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: Org-syntax: Intra-word markup
@ 2021-12-04 21:16 9% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-04 21:16 UTC (permalink / raw)
To: John Kitchin; +Cc: orgmode
Hi John,
John Kitchin writes:
> Along these lines (and combining the s-exp suggestion from Max) , you
> can achieve something like this with links.
I like this idea of merging the Maxim's proposal with the power of links.
In any case, this and other workarounds provided here make it clear that
in Org we do not lack of good and useful resources. I usually use macros
(taking advantage of the fact that macros expand soon). For example
(only in this case with the LaTeX backend):
#+MACRO: emph (eval (when (org-export-derived-backend-p org-export-current-backend 'latex) (concat "@@latex:\\emph{@@" $1 "@@latex:}@@")))
Defined the macro this way, it allows me also to introduce nested
emphases by both ways:
#+begin_src example
{{{emph(lorem *ipsum* /dolor/ {{{emph(sit)}}} amet)}}}
#+end_src
==> \emph{lorem \textbf{ipsum} \emph{dolor} \emph{sit} amet}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Utility of description lists
@ 2022-06-17 14:24 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-17 14:24 UTC (permalink / raw)
To: Cletip Cletip; +Cc: orgmode
Hi,
Cletip Cletip writes:
> - they are made implicitly to make a "key :: value" couple, which can
> be convenient
Leaving aside typographical considerations, what LaTeX calls, for
example, "description" (because Org is totally typographic agnostic), I
find this property that you mention very useful. For example, for my
translation (work in progress) of Homer's Odyssey, I am writing a
descriptive list with the Homeric formulas in Greek (key) and how I
translate each specific formula (value), since they are terms that are
repeated a lot in the text. With a bit of Elisp I can later recover
some specific formula from the list.
See: https://list.orgmode.org/87bl5tzof2.fsf@posteo.net/
Then, when I publish the translation (if I ever finish it ;-)), that
list will be translated in typographic terms, into a glossary of
homeric formulas.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [PATCH] Possibility of using alternative separators in macros
[not found] ` <87im3prvz8.fsf@ucl.ac.uk>
@ 2021-05-11 18:25 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-11 18:25 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 189 bytes --]
Here is the fixed version of the patch.
Best regards,
Juan Manuel
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> Could you create a new patch so I can try this easily?
>
> gracias,
> eric
[-- Attachment #2: 0001-Alternative-args-separator-for-replacement-macros_fixed.patch --]
[-- Type: text/x-patch, Size: 3094 bytes --]
From 4aae61c3600fba136dfa101d54011c0aef9169a3 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macías <maciaschain@posteo.net>
Date: Tue, 11 May 2021 18:41:34 +0200
Subject: [PATCH] Alternative args separator for replacement macros
---
lisp/org-element.el | 11 ++++++++---
lisp/org-macro.el | 9 +++++----
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index a675bf512..da4035689 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -3279,21 +3279,25 @@ CONTENTS is the contents of the object, or nil."
"Parse macro at point, if any.
When at a macro, return a list whose car is `macro' and cdr
-a plist with `:key', `:args', `:begin', `:end', `:value' and
+a plist with `:key', `:args', `:begin', `:end', `:sep', `:value' and
`:post-blank' as keywords. Otherwise, return nil.
Assume point is at the macro."
(save-excursion
- (when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\((\\([^\000]*?\\))\\)?}}}")
- (let ((begin (point))
+ (when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\([^a-zA-Z\s()]*[^-a-zA-Z0-9_\s]*\\)\\((\\([^\000]*?\\))\\)?}}}")
+ (let* ((begin (point))
(key (downcase (match-string-no-properties 1)))
(value (match-string-no-properties 0))
(post-blank (progn (goto-char (match-end 0))
(skip-chars-forward " \t")))
(end (point))
+ (sep (if (not (equal (match-string-no-properties 2) ""))
+ (match-string-no-properties 2)
+ ","))
(args (pcase (match-string-no-properties 3)
(`nil nil)
(a (org-macro-extract-arguments
+ sep
(replace-regexp-in-string
"[ \t\r\n]+" " " (org-trim a)))))))
(list 'macro
@@ -3302,6 +3306,7 @@ Assume point is at the macro."
:args args
:begin begin
:end end
+ :sep sep
:post-blank post-blank))))))
(defun org-element-macro-interpreter (macro _)
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 29c403658..e047cd78e 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -294,20 +294,21 @@ of `org-macro-extract-arguments'."
nil t)
s)))))
-(defun org-macro-extract-arguments (s)
+(defun org-macro-extract-arguments (sep s)
"Extract macro arguments from string S.
S is a string containing comma separated values properly escaped.
-Return a list of arguments, as strings. This is the opposite of
+SEP is the character used to separate arguments. Return a list
+of arguments, as strings. This is the opposite of
`org-macro-escape-arguments'."
;; Do not use `org-split-string' since empty strings are
;; meaningful here.
(split-string
(replace-regexp-in-string
- "\\(\\\\*\\),"
+ (format "\\(\\\\*\\)%s" sep)
(lambda (str)
(let ((len (length (match-string 1 str))))
(concat (make-string (/ len 2) ?\\)
- (if (zerop (mod len 2)) "\000" ","))))
+ (if (zerop (mod len 2)) "\000" (format "%s" sep)))))
s nil t)
"\000"))
--
2.26.0
^ permalink raw reply related [relevance 9%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images export
@ 2023-10-22 21:12 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-22 21:12 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor, sorry for the late reply.
Ihor Radchenko writes:
> So, the difference between :environment and :float is that :float also
> encapsulates \caption in addition to the actual environment (like
> tabularx or includegraphics) used for transcoded exported element.
> I can see how :float+:placement can be imprecise and that the existing
> :environment indeed serves a different purpose. (It might be worth
> clarifying this distinction in the manual - it seems arbitrary from
> the first glance).
> But what would be the better name then?
I think the problem is limited to images, where there is no "double"
environment as in the case of tables (float environment that encloses an
environment to generate the table, and :placement points to the correct
environment). In the case of images, I am afraid that the new features
have advanced the meaning of the old ones. Previously, :float only
supported t/nil ("figure" by default, in case of t) along with a few
explicit "float" environments, such as sidewaysfigure or wrapfigure.
Since :float now can accept any string as an environment name, Pandora's
box has been opened and the meaning of the old :float has been left
behind: for example, we can put :float minipage, and minipage is not a
float environment. Something similar has happened to :placement.
My suggestion is to add a :environment attribute next to another
:environment-options attr (or something like that, to introduce any
arbitrary LaTeX code). A LaTeX image can be enclosed in many environment
types, float or non-float. However, :float can still be useful for
certain combinations. For example, a minipage environment cannot include
a caption (it produces an error of the type "LaTeX Error: \caption
outside float"). Then you would have to put something like
#+ATTR_LaTeX: :float nil :environment minipage :environment-options {\linewidth}
#+CAPTION: caption
[[file:foo.png]]
==>
\begin{minipage}{\linewidth}
\includegraphics[width=.9\linewidth]{foo.png}
\captionof{figure}{caption}
\end{minipage}
Anyway, I find pros and cons of all this:
- pros: a intended feature is added, although with :float and :placement
the same thing can be achieved (sometimes), but here the effect is not
intended (in origin).
- cons: redundancy, more complexity in the code (and probably more confusion for the user?).
--
Juan Manuel Macías
^ permalink raw reply [relevance 9%]
* Re: 'false' list item
@ 2021-02-22 0:21 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-22 0:21 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross <theophilusx@gmail.com> writes:
> The issue is, if we decide this is a bug, can we fix it? Is it a bug or
> is it just an accepted limitation of the org document format and what we
> have to do is ensure either no line starts with a '1. ' or we use
> something like a unicode character so that it doesn't look like a
> number+period+space and therefore not a list item?
Interesting all the points you comment, and this paragraph is important.
I'm thinking that without a clear and explicit environment (a begin/end
marks), any possible solution will always have its exceptions. However,
IMHO, I would not find desirable two explicit marks environment in the
style of LaTeX, since this would go against the virtue of legibility and
lightness in Org. I don't know if Markdown (on what it has in common
with Org as a lightweight markup language) also has similar problems in
lists formatting, since I hardly use Markdown and am not aware of its
many implementations...
I still think that highlighting the items would at least be a preventive
solution for Org.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org mode links: Open a PDF file at a given page and highlight a given string
@ 2021-03-03 16:11 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-03 16:11 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim
Thanks for your advice, which I appreciate very much.
Maxim Nikulin <manikulin@gmail.com> writes:
> On 03/03/2021 09:31, Juan Manuel Macías wrote:
>> (start-process-shell-command "zathura" nil (concat "zathura "
>> clean-path
>> " -P "
>> pag
>> (when str
>> (format " -f '%s' " str)))))))
>
> Please, do not forget to pass stings coming from user input through
> shell-quote-argument. There is combine-and-quote-strings function but
> its docstring tells that it is not safe enough. Ideally shell should
> be completely avoided in such cases and arguments should be passed as
> a list directly to exec. https://xkcd.com/327/
So, maybe it would look better like this (`start-process' instead of
`start-process-shell-command')?:
#+begin_src emacs-lisp
(org-link-set-parameters
"pdf-pag"
:follow (lambda (path)
(let ((pag (if (string-match "::\\([1-9]+\\):*:*\\(.*\\)" path)
(format "--page=%s" (match-string 1 path))
(error "no pages")))
(clean-path (expand-file-name (replace-regexp-in-string "::.+" "" path)))
(str (when (string-match "::\\([1-9]+\\)::\\(.+\\)" path)
(format "--find=%s" (match-string 2 path)))))
(if str
(start-process "zathura" nil "/usr/bin/zathura"
clean-path
pag
str)
(start-process "zathura" nil "/usr/bin/zathura"
clean-path
pag)))))
#+end_src
Best reagards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-critical-edition (a package for philologists and classicists)
@ 2021-06-15 12:44 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-15 12:44 UTC (permalink / raw)
To: Christian Moe; +Cc: orgmode
Hi Christian, thank you very much for your comments.
Christian Moe writes:
> Very neat!
>
> Curious about a design choice: If I understand correctly,
> org-critical-edition puts the hidden notes in the description and the
> visible annotated text in the target of an org link. This is the reverse
> of the out-of-the-box link appearance (description visible, target
> hidden if description present). Why take the extra trouble to do it this
> way?
>
Indeed, the decision to reverse the order of the link appearance may
seem somewhat shocking :-) I did it like this to keep a syntactic
structure similar to the reledmac command \edtext, when the user (the
reledmac user) views the links full displayed. In LaTeX/reledmac the
structure is:
...some text... \edtext{annotated passage}{critical notes} ...some text...
The annotated passage is part of the text and is also the "lemma" in the
critical note.
In org-critical-edition I define a new link type called `edtext', using
`org-link-set-parameters', and the identifying string (`edtext:') must be
placed in the target part.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [tip] Org speed commands improved
@ 2022-04-27 7:08 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-04-27 7:08 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi Ihor,
Ihor Radchenko writes:
> If you are going this far with speed commands, you might as well switch
> to modal editing. What you are describing is basically a modal command
> map with ability to switch to insert map.
I'm not a fan of modal editing, rather the opposite. But in this
particular case I have found that I spend very little time editing the
raw content of the headers, once I set it. I spend more time editing the
'meta-content': TODO states, properties, tags, refile, attached folders,
etc. And that with the speed commands can be achieved in a very agile
way, so that a small dose of controlled modal editing and reduced only
to the header, maybe it's worth it :-) If the speed commands were also
activated in the content of the sections, here we would have a real
modal editing, and that (in my case) would not be comfortable.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Macros and possible alternatives to the comma character (enhancement?)
@ 2021-02-12 13:01 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-12 13:01 UTC (permalink / raw)
To: orgmode
Hi,
In my Org docs I make a heavy use of replacement macros. I think they
are a powerful and versatile. I only see one problem: in my opinion, the
comma as a character to separate arguments seems unproductive to me. I
often use macros to enter textual content, and I find it a bit tedious
having to constantly escape such a common symbol as the comma (\,). In fact,
for my personal use I have modified the `org-macro-extract-arguments'
function, and now I separate the arguments using '@ (quote + at).
Am I the only one who thinks there should be better alternatives to the
comma?
Do you think it would be good to add these alternatives as a '#+startup'
option?
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Bug: alphabetical lists will not show up as such in LaTeX export [9.3.6 (9.3.6-71-g7684b5-elpaplus @ /home/qqwy/.emacs.d/elpa/org-plus-contrib-20200518/)]
@ 2021-03-05 12:01 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-05 12:01 UTC (permalink / raw)
To: Qqwy/Wiebe-Marten; +Cc: orgmode
Hi,
Qqwy/Wiebe-Marten <qqwy@gmx.com> writes:
> However, the LaTeX that is exported will still create normal `enumerize`
> lists that do /not/ show up as alphabetical but rather still use `1.`,
> `2.`, `3.` for numbering.
>
> I think this current behaviour is at the very least surprising, and
> possibly unintended.
I use the enumitem package
(http://mirrors.ctan.org/macros/latex/contrib/enumitem/enumitem.pdf) for
lists in LaTeX. For an alphabetical list, for example:
#+begin_src org
,#+LaTeX_Header: \usepackage{enumitem}
,#+ATTR_LaTeX: :options [label=\alph*.,widest=a]
a. Lorem
b. ipsum
c. dolor
#+end_src
And to export to LaTeX and HTML, you can define a macro like this:
#+begin_src org
,#+MACRO: alphalist (eval (if (org-export-derived-backend-p org-export-current-backend 'latex) "#+ATTR_LaTeX: :options [label=\\alph*.,widest=a]" "#+ATTR_HTML: :type a"))
{{{alphalist}}}
a. Lorem
b. ipsum
c. dolor'
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Filter for HTML footnotes?
@ 2022-03-06 4:03 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-03-06 4:03 UTC (permalink / raw)
To: M. ‘quintus’ Gülker; +Cc: orgmode
M. ‘quintus’ Gülker writes:
> I recently discovered export filters and found some useful applications
> for them. For instance, the scientific domain I work in (law) uses
> footnote citations, and in these footnotes we abbreviate some words
> which would otherwise be written out in ordinary text, like name
> particles. Since I use org-cite these footnotes are automatically
> generated. So what I did was to write a filter which abbreviates these
> words on export in footnotes. I added the filter function to both
> org-export-filter-footnote-definition-functions and
> org-export-filter-footnote-reference-functions and indeed, when I export
> to LaTeX or ODT it does its job just fine. However, when I export to
> HTML instead, it does not. When I looked at the text passed to the
> filter when exporting as HTML, it turned out what the function receives
> is not the content of the footnote, but only the markup for the footnote
> number. That came a bit by surprise.
> So, what is the correct way to target the content of a footnote in a
> filter across backends?
Hi,
I think a function for `org-export-filter-parse-tree-functions' would
work better here. For example, this function replaces "lorem ipsum" with
"foo" in all footnote definitions:
#+BIND: org-export-filter-parse-tree-functions (fnt-filter-replace)
#+begin_src emacs-lisp :exports results :results none
(defun fnt-filter-replace (tree backend info)
(org-element-map tree 'footnote-definition
(lambda (fnt)
(let* ((contents (org-element-interpret-data
(org-element-contents fnt)))
(contents-new (with-temp-buffer
(insert contents)
(save-excursion
(goto-char (point-min))
(while (re-search-forward "lorem ipsum" nil t)
(replace-match "foo" t nil)))
(org-element-parse-buffer))))
(apply #'org-element-set-contents
fnt
(list contents-new))))
info)
tree)
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [External] : Re: missing a character / font in agenda?
@ 2022-07-12 19:52 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-12 19:52 UTC (permalink / raw)
To: Daniel Ortmann; +Cc: orgmode
Hi, Daniel,
Daniel Ortmann writes:
> – Would using the ASCII '<' character be a better solution?
I've done a quick test and a few very popular (and more or less
complete) fonts don't include a glyph for the LEFTWARDS TRIANGLE-HEADED
ARROW #2b60 character: DejavuSans, Iosevka, Hack Source Code Pro,
JuliaMono or Fira Code. It is a very rare symbol.
> – Is anyone else seeing this issue and missing font?
I haven't seen it, but I'm not using the Git version.
> – Is that Symbola font, or equivalent, now a true dependency? Or is
> there something more common which I should be using? (Perhaps I
> have missed a normal configuration step?)
I think Symbola should not be a dependency. I use this font just to be
able to display unusual symbols, especially on web pages when I browse
the web with eww-mode. The most reasonable thing would be to use a more
common symbol. But I'm still intrigued by the origin of that symbol...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org-syntax: emphasis and not English punctuation
@ 2021-12-04 16:42 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-04 16:42 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> Maybe this issue should be considered independently of itra-word emphasis.
Yes I agree. Apologies for mixing up this topic in the discussion about
intra-word emphasis...
> Second and third examples looks like they should be supported. Ihor
> mentioned treating punctuation in a more general way. It requires rich
> test set to estimate changes in heuristics. I suspect some problems
> since start and end patterns are not symmetric and I have not found a
> way to specify in regexp only punctuation marks that normally appears
> in front of words. Square brackets likely should be excluded somehow
> as well since they are part of Org syntax. I am unsure if it is
> possible to use just regexp without additional checks of candidates.
Ihor's idea seems interesting to me, although I understand the possible
problems you mention. By the way, I'm afraid of initial inverted
punctuation (¡¿) are only used in Castilian Spanish and other languages
of Spain, such as Galician or Asturian, due to the Castilian influence
(we go backwards from the rest of the world ;-):
https://en.wikipedia.org/wiki/Inverted_question_and_exclamation_marks
> Ihor Radchenko. [PATCH] Re: c47b535bb origin/main org-element: Remove
> dependency on ‘org-emphasis-regexp-components’
> Sun, 21 Nov 2021 17:28:57 +0800.
> https://list.orgmode.org/87v90lzwkm.fsf@localhost
I see. I believe it's a sensible decision to get rid of the dependency
on org-emphasis-regexp-components. I understand that now everything
related to the structure of emphases is the competence of org-element?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Playing down the text in org-mode
@ 2022-01-14 20:00 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-14 20:00 UTC (permalink / raw)
To: fatiparty; +Cc: orgmode
fatiparty--- via "General discussions about Org-mode." writes:
> What is the face name associated with inline footnotes?
M-x describe-face RET Is your friend. Place the cursor on any inline
note, run this command and you will see that the face you need to modify
is called `org-footnote'.
M-: (info "(elisp)faces") RET
With this you have at your disposal all the information about faces, how
to manipulate them, etc.
I use a lot the `set-face-attribute' function in my init, to modify some
things of the theme that I have loaded. For example, if you want to
change the color of your notes and make them a little smaller in size:
(set-face-attribute 'org-footnote nil :foreground "DimGray" :height 0.9)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [PATCH] speed commands: error message when a key is not associated with a command
@ 2022-05-01 11:00 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-01 11:00 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> This would not solve the problem of shadowing.
> It may be better idea to provide a custom variable controlling
> org-babel-speed-command-activate: do nothing or throw an error.
> This custom variable should also be described in the docstring of
> org-speed-command-hook to warn about potential shadowing.
>
> To summarise, your idea will be reasonable if:
> 1. The new behaviour can be customized
> 2. The new behaviour is documented in org-speed-command-hook
Ok, I agree that this is the most reasonable direction. What do you
think about the idea that I outlined in the last post of this thread
(https://list.orgmode.org/87v8uqmkc0.fsf@posteo.net/)?: it consists in
defining a new hook (by default with value nil) where the user can store
those functions that he wants to have a 'strict' behavior: some functions
or all. And then the user should add the
org-speed-command-strict-function to org-speed-command-hook.
If this idea sounds too hacky, I think a defcustom for
org-babel-speed-command-activate, as you suggest, might suffice.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
@ 2024-01-20 13:22 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-20 13:22 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Max Nikulin
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> \begin{itemize}
>>> \item {[}bax]
>>> \item {[}aur]
>>> \end{itemize}
>>
>> Great! Simple and effective. And more surgical than pandoc's global
>> solution. But now a question arises... Your code clearly solves the
>> problem that led to the declaration of org-latex-line-break-safe,
>> without foreseeing any unwanted effects, since it is the solution that
>> is usually recommended from LaTeX. So, if this code is included in Org,
>> what is the future of org-latex-line-break-safe?
>
> It is still useful in situations like
>
> Paragraph\\
>
> #+begin_export latex
> [foo]
> #+end_export
>
> or
>
> Paragraph\\
> @@latex:[foo]@@
But since in both cases it is literal LaTeX code, the correct thing
would be for the user to be in charge of adding the curly braces to the
square brackets. I mean in such scenario it is LaTeX code, not Org.
Anyway, in both examples it does not make sense for LaTeX to end a
paragraph with the \\ macro, which is why we commented in previous
messages in the thread. The \\ macro is only used in horizontal mode;
this macro does not add a new paragraph but rather a forced line break
within the paragraph.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: How to expand macro in LaTeX export? How to use different options per export type?
@ 2021-04-03 21:57 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-03 21:57 UTC (permalink / raw)
To: Jean Louis; +Cc: orgmode
Jean Louis writes:
> Another issue related to this setup is that I would like:
>
> - for HTML export: title:t toc:t
>
> - for LaTeX PDF export: title:nil toc:nil
>
> Is there way to have options different for different exports?
You can do it with a macro like this:
#+MACRO: titletoc (eval (cond ((org-export-derived-backend-p org-export-current-backend 'latex) "#+OPTIONS: title:nil\n#+OPTIONS: toc:nil")((org-export-derived-backend-p org-export-current-backend 'html) "#+OPTIONS: title:t\n#+OPTIONS: toc:t")))
{{{titletoc}}}
...
But maybe it would be better to use a block here:
#+begin_src emacs-lisp :exports results :results raw
(cond ((org-export-derived-backend-p org-export-current-backend 'latex)
"#+OPTIONS: title:t\n#+OPTIONS: toc:t")
((org-export-derived-backend-p org-export-current-backend 'html)
"#+OPTIONS: title:nil\n#+OPTIONS: toc:nil"))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Exporting multiple #+AUTHOR keywords
@ 2024-02-04 22:13 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-04 22:13 UTC (permalink / raw)
To: Max Nikulin; +Cc: Ihor Radchenko, orgmode
Max Nikulin writes:
> On 04/02/2024 22:21, Ihor Radchenko wrote:
>>
>> Another option is to have a new set of keywords:
>> #+LATEX_AUTHOR: <author with formatting goes here>
>> #+HTML_AUTHOR: ...
>>
>> For multiple authors, we may introduce something like
>>
>> #+AUTHOR: John Doe
>> #+AUTHOR+: Luke Skywalker
>
> Another idea:
>
> #+metadata:
> - author ::
> - John Doe
> - Luke Skywalker
> - title :: Some text
>
> With overrides for specific backends
>
> #+metadata: :backend latex
> - author :: ....
>
> Perhaps backends may declare if they support footnotes, etc. by defining
> some backend property.
I like both ideas. If I had to choose, perhaps I would prefer Ihor's
approach since it separates the formatting value and the metadata value
using simple keywords. I understand that in the former you could add any
direct format (LaTeX, odt, html...), macros and even footnotes. And if
the former is not explicitly included in the document, then the latter
is used to populate both the formatting value and the metadata value.
Anyway, I think your approach would work very well for more complex pdf
metadata like xmp. Maybe using the hyperxmp package, which you mentioned
in a thread months ago?
Maybe something like this:
#+latex_xmp
...
#+end
?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
@ 2023-09-28 12:31 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-28 12:31 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> LaTeX code may be inserted
> - before \DocumentMetadata
> - between \DocumentMetadata and \documentclass
> - between \documentclass and preamble added by Org
> - between Org preamble and \begin{document}
The first two cases can be solved perfectly with LaTeX_pre_header,
without having to complicate your life further.
> Since ordering is important [...]
Starting with \documentclass, the order is important in certain cases
and not so important in others. And, anyway, you can always use a hook
like \AtBegin... \AtEnd..., etc.
And if users want to have complete control over the preamble (that is,
everything before \begin{document}), they can always define a new class
(in Org terminology) or write a preamble or a sty file in a separate Org
document using org-babel and literary programming. In a job I'm doing
now my preamble has 1736 lines. Writing it with org-babel is quite
comfortable. In short, I think (IMHO) Org already has enough resources
for those situations.
> I consider \begin{filecontents*}{\jobname.xmpdata} as an acceptable
> (but perhaps fragile) hack for LaTeX-first document. During export of
> Org file, this file should be written directly with values from Org
> metadata.
I think I should insist on what I said in my previous message, with a
copy/paste:
The thing is that here it is not a question of whether something can be
done in this way or in another better way. This is how a given package
recommends doing it. If the user wants to use that specific package, she/he
will have to follow these instructions. It's more. I am thinking, for
example, of the case in which the user has to obtain a * tex file, not a
PDF, because she/he is collaborating with more people who do not use
Org, but do use that code in the * tex document.
Apart from that, since any code (except \usepackage) is allowed before
\documentclass, I think that the user should have the possibility (and
the freedom) to enter in their *tex documents whatever they want in that
place, including comments, luacode, shebangs, etc.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* [off-topic] E-readers and Org-Mode
@ 2022-10-23 15:16 9% Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-10-23 15:16 UTC (permalink / raw)
To: orgmode
Hi all,
As I am beginning to have serious eye fatigue problems, I am thinking of
buying an e-ink device, not to read books but to read documents. My idea
is that it be an Android device and that it supports the installation of
apk, to be able to install Termux/Emacs/Org-Mode and Nextcloud to sync
with my desktop PC or my laptop. I'd like to explore a workflow where I
could read PDFs on the device (and probably also text-only web pages
with eww) and also take Org Mode notes.
I wonder if anyone has tried something similar, if there is anything
written about it somewhere or if it is completely uncharted territory.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
@ 2023-10-02 14:55 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-02 14:55 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> ┌────
>> │ #+caption: Main caption
>> │ #+begin_figure
>> │ #+CAPTION: subcaption 1
>> │ #+ATTR_LaTeX: :float subfigure :placement {\textwidth} :center nil :width \textwidth
>> │ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
>> ...
>> I think this is a case where certain elements of Org have evolved
>> (consciously or unconsciously) ahead of the names, and these names have
>> become somewhat outdated. There is not only the case of :placement. Even
>> :float seems imprecise, since can be used to create a minipage, and the
>> minipage environment is not a float environment. Would it be worth
>> making those names obsolete (with backward compatibility, of course) and
>> replacing them with slightly more precise ones? I think that new names
>> would give the user an idea of more variety of uses, like the examples I
>> have put here.
>
> I am not sure about obsolete - I see not reason to obsolete the intended
> use case. Your example is rather an abuse.
Why abuse? First, it works like a charm. Second, if :float can support
any string as an environment name, why not minipage or subfigure? As for
:placement, the term would seem more precise to me if it were really
"placement" (as :align in tables is actually "align"), not LaTeX code
passed directly after the \begin{...}. That a user can put things like
this (I do it often, and I think I'm not the only one):
:placement [htbp]\SomeExtraLaTeXCode...
it is a consequence of the above. It is not an "orthodox" use (I mean,
it's not described in the manual), but it works without problems. Again,
I don't want to seem too picky about the names, but a user who doesn't
understand the source code might think that :placement only supports
things like [htbp]. My idea here is: instead of implementing new
features, recycle and take advantage of those that arise unexpectedly
:-). Although :placement was created thinking about putting code related
to placement figures, as it is implemented I would have called it
:latex-code or something similar.
> What we might do it to introduce something like a new :wrap attribute:
>
> #+attr_latex: :wrap subfigure,{\textwidht}
That would be nice if with a single latex_attr line you could export a
single figure environment for several images, since every subfigure
environment must be inside a figure environment. And putting a single
subfigure inside a figure environment doesn't make much sense. Other
than that, the idea of :wrap is good. I find it very useful, especially
on tables.
> I think we have discussed something similar in the past, but more
> generic - allow wrapping arbitrary Org elements (headings, drawers,
> paragraphs, etc) on export.
I remember that thread. In fact, I think I created a TODO to study that,
but due to lack of time I haven't been able to take a look at it.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: how to export to odt with 11 or 10 pt fonts? Default font setting
@ 2021-10-07 12:58 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-07 12:58 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Thanks, but it seems 11TeXpt-->10.95
>
> So it is not that different.
In typography it's a significant difference. It's not dramatic, but it
can produce different results in a book using the same body text and the
same line spacing, same margins, page dims. etc. Also TeX uses more
decimals. It all depends on more factors, of course: the font or the
microtype properties of pdfTeX and LuaTeX, especially horizontal
scaling, which can also have a significant influence, when activated, on
the appearance of text and pagination.
In any case, what I said was nothing more than a fun typographic fact,
since most people think that there is only one type of point.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.)
@ 2021-06-08 0:24 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-08 0:24 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 203 bytes --]
As I commented in a previous post of this thread, to reproduce the
bug, just run `org-toggle-link-display'.
As a possible solution I'm attaching this patch (little tested).
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org.el-prevent-partial-fontification-link-display-full.patch --]
[-- Type: text/x-patch, Size: 1252 bytes --]
From caf32a7e1fb1b4bddfa011520f5403d5b6b19ddd Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 8 Jun 2021 01:55:02 +0200
Subject: [PATCH] org.el: prevent partial fontification when a link is
displayed full
* lisp/org.el (org-activate-links): apply `face-property' variable in
other cases when handle invisible parts in bracket links
---
lisp/org.el | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 1bd9e02eb..b55d8798a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5224,9 +5224,11 @@ This includes angle, plain, and bracket links."
,(or (org-link-get-parameter type :display)
'org-link))
properties)))
+ (add-face-text-property start visible-start face-property)
(add-text-properties start visible-start hidden)
- (add-face-text-property visible-start visible-end face-property)
+ (add-face-text-property visible-start visible-end face-property)
(add-text-properties visible-start visible-end properties)
+ (add-face-text-property visible-end end face-property)
(add-text-properties visible-end end hidden)
(org-rear-nonsticky-at visible-start)
(org-rear-nonsticky-at visible-end)))
--
2.31.1
^ permalink raw reply related [relevance 9%]
* [PATCH] ox-latex: fix `org-latex-guess-babel-language'
@ 2022-11-14 22:46 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-14 22:46 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
If the user puts a string other than AUTO as an argument to
`\babelprovide', it gives an error when exporting. For example:
`#+LaTeX_Header: \babelprovide[<options>]{hebrew}'
I am attaching a patch to fix that behaviour.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-fix-org-latex-guess-babel-language.patch --]
[-- Type: text/x-patch, Size: 1450 bytes --]
From 6dcba41f58b355296c3cacf97be9508581e1a10a Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 14 Nov 2022 23:33:16 +0100
Subject: [PATCH] lisp/ox-latex.el: fix `org-latex-guess-babel-language'
* (org-latex-guess-babel-language): If the user puts a string other
than AUTO as an argument to `\babelprovide', it gives an error when
exporting. For example:
`#+LaTeX_Header: \babelprovide[onchar=ids,import]{hebrew}'
---
lisp/ox-latex.el | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 9bdb9fb63..095f6b51c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1669,12 +1669,13 @@ Return the new header."
(if (not (string-match "\\\\babelprovide\\[.*\\]{\\(.+\\)}" header))
header
(let ((prov (match-string 1 header)))
- (when (equal "AUTO" prov)
- (replace-regexp-in-string (format
- "\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
- (format "\\1\\2%s}"
- (or language language-ini-only))
- header t))))))
+ (if (equal "AUTO" prov)
+ (replace-regexp-in-string (format
+ "\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
+ (format "\\1\\2%s}"
+ (or language language-ini-only))
+ header t)
+ header)))))
(defun org-latex-guess-polyglossia-language (header info)
"Set the Polyglossia language according to the LANGUAGE keyword.
--
2.38.1
^ permalink raw reply related [relevance 9%]
* Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
@ 2021-01-25 17:46 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-25 17:46 UTC (permalink / raw)
To: Gustavo Barros; +Cc: orgmode
Hi Gustavo,
Gustavo Barros <gusbrs.2016@gmail.com> writes:
> I'd also would love to see that. ;-)
>
> And I do think Org is, by far, the best placed tool to fill this
> place. But I also think citations and bibliography are a big
> bottleneck in that regard. Of course, there is a long ongoing effort
> in that area, in the `wip-cite' branch, and the related `org-citeproc'
> package. I'm still in the hope this will get merged in future not too
> distant, as it would change things in that regard. Not in the sense
> of "magically solving all of these problems", but in providing a
> convened base upon which people can than invest their time and effort,
> and try to figure each case out, with time.
I totally agree.
By the way... I have written some code to export the citations using
make4ht. It's just a proof of concept, and not too elegant I'm afraid.
But I wanted to explore a bit more the use of make4ht in this context.
The idea is to write the citations in Org as mere bibLaTeX commands, but
between !!- ... -!! (a provisional regexp, for convenience, and to see
if it works). It can be tested in this Org file, which includes the code
(you have to give a value to the variables `bib' and `preamble'):
https://gitlab.com/-/snippets/2066135
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org mode links: Open a PDF file at a given page and highlight a given string
@ 2021-03-03 2:31 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-03 2:31 UTC (permalink / raw)
To: Rodrigo Morales; +Cc: orgmode
Hi Rodrigo,
Rodrigo Morales <moralesrodrigo1100@gmail.com> writes:
> I want to be able to
>
> + create a Org link to specific pages of a PDF. I've managed to
> accomplish this by setting the following value.
> [ ... ]
> + create a Org link to specific pages of a PDF and highlight a given
> string.
A possible alternative, which gives you more control over the link, is
`org-link-set-parameters'. For example:
#+begin_src emacs-lisp
(org-link-set-parameters
"pdf-pag"
:follow (lambda (path)
(let ((pag (if (string-match "::\\([1-9]+\\):*:*\\(.*\\)" path)
(match-string 1 path)
(error "no pages")))
(clean-path (expand-file-name (replace-regexp-in-string "::.+" "" path)))
(str (when (string-match "::\\([1-9]+\\)::\\(.+\\)" path)
(match-string 2 path))))
(start-process-shell-command "zathura" nil (concat "zathura "
clean-path
" -P "
pag
(when str
(format " -f '%s' " str)))))))
#+end_src
And then:
#+begin_src org
[[pdf-pag:~/Downloads/grub.pdf::95::do]]
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
Results 401-600 of ~1200 next [<= 8%] | prev [>= 9%] | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
[not found] <mailman.57.1645549224.6185.emacs-orgmode@gnu.org>
2022-02-22 22:30 ` Footnote tooltips (an attempt) Ypo
2022-02-23 2:26 9% ` Juan Manuel Macías
[not found] ` <CAJcAo8tsK5o+789Wv=i6ddiSrM4fDyX8HCvjAgDLXGyLXWRWmQ@mail.gmail.com>
2022-02-23 19:52 9% ` Juan Manuel Macías
2022-01-04 10:14 9% A simple Lua filter for Pandoc Juan Manuel Macías
2022-01-04 14:05 ` Max Nikulin
2022-01-04 15:06 ` Juan Manuel Macías
2022-01-05 16:29 ` Max Nikulin
2022-01-05 17:08 9% ` Juan Manuel Macías
2022-01-07 14:29 ` Max Nikulin
2022-01-07 15:14 8% ` Juan Manuel Macías
2020-12-20 21:37 9% Displaying verse numbers within a verse block Juan Manuel Macías
2022-04-10 8:49 9% Save Gnus attachments to Org using org-attach and helm-org-ql Juan Manuel Macías
2021-09-19 16:30 9% [PATCH] ox.el: add smart quotes for Greek Juan Manuel Macías
2021-09-20 14:54 ` Max Nikulin
2021-09-21 20:20 ` Juan Manuel Macías
2021-09-22 17:19 ` Max Nikulin
2021-09-22 19:55 8% ` Juan Manuel Macías
2021-09-23 16:10 ` Max Nikulin
2021-09-23 17:17 8% ` Juan Manuel Macías
2021-02-16 16:30 9% [question] lisp code in :results header arg.? Juan Manuel Macías
2022-05-15 11:54 9% [tip] Export and open a PDF in Android via Termux Juan Manuel Macías
2022-05-16 15:00 ` Max Nikulin
2022-05-16 16:05 ` Juan Manuel Macías
2022-05-17 16:22 ` Max Nikulin
2022-05-17 17:56 ` Juan Manuel Macías
2022-05-19 9:40 ` Eric S Fraga
2022-05-19 18:01 8% ` Juan Manuel Macías
2022-02-22 4:32 9% Footnote tooltips (an attempt) Juan Manuel Macías
2021-03-01 12:55 9% [tip for EXWM users] An alternative method for isolate trees Juan Manuel Macías
2022-08-16 15:19 9% [off topic] List all non-latin characters in a buffer Juan Manuel Macías
2021-06-18 12:11 9% A dictionary made in Org Mode Juan Manuel Macías
2024-02-20 20:35 9% [proof of concept] inline language blocks Juan Manuel Macías
2022-04-26 14:00 9% [tip] Org speed commands improved Juan Manuel Macías
2022-04-27 4:20 ` Ihor Radchenko
2022-04-27 7:08 9% ` Juan Manuel Macías
2021-03-15 17:10 9% Nested macros and fontification Juan Manuel Macías
2020-12-10 22:17 9% Accessing a DLNA server through an Org link Juan Manuel Macías
2022-01-16 16:42 9% [ann] org-font-spec-preview (preview fonts and test open type features) Juan Manuel Macías
2021-05-22 14:12 9% [PATCH] org.el: use only link descriptions in indirect buffer names Juan Manuel Macías
2022-01-07 0:41 9% Filter to put decorative initial letters Juan Manuel Macías
2022-10-23 15:16 9% [off-topic] E-readers and Org-Mode Juan Manuel Macías
2022-10-25 14:37 ` Max Nikulin
2022-10-25 15:21 ` Fraga, Eric
2022-10-25 16:59 ` Ken Mankoff
2022-10-27 17:20 ` Max Nikulin
2022-10-27 17:53 ` Juan Manuel Macías
2022-10-29 12:54 ` Max Nikulin
2022-10-31 12:18 8% ` Juan Manuel Macías
2021-01-12 22:30 9% A minor mode for inserting things while typing Juan Manuel Macías
2022-05-12 10:44 9% citation-style-language: new LaTeX package in TL 2022 Juan Manuel Macías
2022-01-08 11:32 9% [tip] Inline tasks as anonymous sections Juan Manuel Macías
2022-04-30 11:25 9% [PATCH] speed commands: error message when a key is not associated with a command Juan Manuel Macías
2022-04-30 13:06 ` Ihor Radchenko
2022-04-30 14:41 8% ` Juan Manuel Macías
2022-04-30 19:39 8% ` Juan Manuel Macías
2022-05-01 4:01 ` Ihor Radchenko
2022-05-01 11:00 9% ` Juan Manuel Macías
[not found] <mailman.47.1614445226.20994.emacs-orgmode@gnu.org>
2021-02-27 18:57 ` content management in emacs Ian Garmaise
2021-02-27 19:16 ` Martin Steffen
2021-02-27 20:11 9% ` Juan Manuel Macías
2021-05-31 10:40 9% An attempt to convert Elfeed entries (with parameters) to Org trees Juan Manuel Macías
2022-03-05 19:58 9% Move or rename a file in a link Juan Manuel Macías
2021-10-26 16:05 9% [patch] ox-latex.el: add `:options' LaTeX attribute to tables Juan Manuel Macías
2022-01-30 12:32 9% A callygraphy notebook environment Juan Manuel Macías
2022-01-30 20:37 ` Uwe Brauer
2022-01-30 21:23 9% ` Juan Manuel Macías
2024-03-05 0:58 9% [tip] Export to PDF with latexmk 'continuous preview' option Juan Manuel Macías
2021-08-06 10:33 9% "Continuous Integration and TeX with Org-Mode", by Rohit Goswani (TUG 2021) Juan Manuel Macías
2021-04-02 18:15 9% [Patch] to correctly sort the items with emphasis marks in a list Juan Manuel Macías
2021-04-09 22:28 ` Nicolas Goaziou
2021-04-10 0:01 ` Juan Manuel Macías
2021-04-17 13:27 ` Maxim Nikulin
2021-04-18 17:52 9% ` Juan Manuel Macías
2021-04-18 21:20 ` Juan Manuel Macías
2021-04-19 8:33 ` Nicolas Goaziou
2021-04-19 12:34 ` Maxim Nikulin
2021-04-19 16:08 ` Nicolas Goaziou
2021-04-20 12:20 ` Maxim Nikulin
2021-04-20 13:57 ` Nicolas Goaziou
2021-04-20 15:51 ` Maxim Nikulin
2021-04-20 20:37 ` Nicolas Goaziou
2021-04-21 13:10 ` Maxim Nikulin
2021-04-21 15:45 9% ` 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 9% ` Juan Manuel Macías
2021-04-14 15:42 ` Maxim Nikulin
2021-04-14 17:07 9% ` Juan Manuel Macías
2021-04-15 14:58 ` Maxim Nikulin
2021-04-15 18:21 9% ` Juan Manuel Macías
2022-11-14 22:46 9% [PATCH] ox-latex: fix `org-latex-guess-babel-language' Juan Manuel Macías
2023-10-22 21:12 9% Are 'placement' and 'float' "obsolete terms" in inline images export Juan Manuel Macías
2022-11-01 16:55 9% Line breaks and brackets in LaTeX export Juan Manuel Macías
2022-08-08 14:39 9% [PATCH] Documentation and NEWS for ` org-latex-language-alist' Juan Manuel Macías
2022-06-30 14:19 9% Convert a Lisp expression to a tree diagram Juan Manuel Macías
2024-02-10 1:58 9% [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 ` Juan Manuel Macías
2024-02-10 16:35 ` Ihor Radchenko
2024-02-10 17:48 ` Juan Manuel Macías
2024-02-10 19:35 ` Juan Manuel Macías
2024-02-10 21:07 ` Ihor Radchenko
2024-02-10 23:34 ` Juan Manuel Macías
2024-02-11 14:43 ` Ihor Radchenko
2024-02-11 20:01 9% ` Juan Manuel Macías
2021-11-23 16:52 9% Dired images in an Org buffer Juan Manuel Macías
2021-02-12 13:01 9% Macros and possible alternatives to the comma character (enhancement?) Juan Manuel Macías
2021-10-07 14:57 8% [tip] Go to the org node from the attached directory Juan Manuel Macías
2022-07-16 14:33 8% Org for developing LaTeX packages Juan Manuel Macías
2021-03-25 9:40 8% An interesting LaTeX package Juan Manuel Macías
2022-10-05 9:49 8% A function to perform Org related searches in several places Juan Manuel Macías
2021-05-10 7:19 8% [tip] Export annotations with the 'Mindflow' LaTeX package Juan Manuel Macías
2022-02-22 16:04 8% Open a footnote definition outside a narrowed subtree (workaround) Juan Manuel Macías
2021-04-05 9:25 8% [tip] search this mailing list with helm-surfraw Juan Manuel Macías
2023-08-06 12:03 8% [patch] ox-latex.el: fix blank lines behavior in verse block Juan Manuel Macías
2023-08-07 11:40 ` Ihor Radchenko
2023-08-07 17:23 9% ` Juan Manuel Macías
2021-12-03 12:48 8% On zero width spaces and Org syntax Juan Manuel Macías
2021-12-03 19:03 ` Greg Minshall
2021-12-03 20:30 9% ` Juan Manuel Macías
2022-02-11 20:37 8% [PATCH] org-manual.org: update and add info for arbitrary :float values Juan Manuel Macías
2022-06-25 3:10 8% Org inside LaTeX (a poor man's approach with LuaTeX) Juan Manuel Macías
2020-12-23 2:11 8% [TIP] Export to LaTeX and HTML with a watermark Juan Manuel Macías
2021-04-30 13:26 [PATCH] Possibility of using alternative separators in macros Juan Manuel Macías
2021-05-11 11:01 ` Eric S Fraga
2021-05-11 16:12 ` Juan Manuel Macías
[not found] ` <87im3prvz8.fsf@ucl.ac.uk>
2021-05-11 18:25 9% ` Juan Manuel Macías
2021-05-15 13:29 ` Bastien
2021-05-15 20:14 9% ` Juan Manuel Macías
2021-05-24 12:14 [PATCH] ox-latex.el: add LaTeX attributes to quote block Juan Manuel Macías
2021-05-25 9:21 ` Nicolas Goaziou
2021-05-25 12:42 8% ` 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 ` Juan Manuel Macías
2024-01-24 15:31 ` Colin Baxter
2024-01-24 15:41 9% ` Juan Manuel Macías
2024-01-26 12:53 ` Ihor Radchenko
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 ` 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 ` Exporting multiple #+AUTHOR keywords Juan Manuel Macías
2024-02-04 15:21 ` Ihor Radchenko
2024-02-04 16:16 ` Max Nikulin
2024-02-04 22:13 9% ` 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 ` Juan Manuel Macías
2023-09-25 13:58 ` Max Nikulin
2023-09-25 18:49 9% ` Juan Manuel Macías
2023-09-25 21:57 ` Thomas S. Dye
2023-09-26 15:39 ` Max Nikulin
2023-09-26 19:12 9% ` Juan Manuel Macías
2023-09-28 10:07 ` Max Nikulin
2023-09-28 12:31 9% ` Juan Manuel Macías
2021-02-01 12:51 emphasizing source code words Luca Ferrari
2021-02-01 12:55 ` TEC
2021-02-04 11:38 ` Luca Ferrari
2021-02-04 12:13 9% ` Juan Manuel Macías
2022-05-07 23:43 Export LaTeX command inside figure environment Thomas S. Dye
2022-05-08 0:30 ` Juan Manuel Macías
2022-05-08 5:08 ` Max Nikulin
2022-05-08 6:06 ` Thomas S. Dye
2022-05-08 16:12 8% ` Juan Manuel Macías
2022-01-12 13:08 puzzled about :fit for LaTeX src block Eric S Fraga
2022-01-12 17:22 ` Juan Manuel Macías
2022-01-13 10:14 ` Eric S Fraga
2022-01-13 11:17 ` Juan Manuel Macías
2022-01-13 12:05 ` Eric S Fraga
2022-01-13 15:41 8% ` Juan Manuel Macías
2022-07-18 6:57 org-table with different conventions: decimals Uwe Brauer
2022-07-18 23:02 9% ` Juan Manuel Macías
2022-07-25 19:02 How to force markup without spaces K
2022-07-26 1:26 ` Ihor Radchenko
2022-07-26 2:23 ` Max Nikulin
2022-07-26 4:26 ` K K
2022-07-26 12:59 ` [PATCH] org-export: Remove zero-width space escapes during export Ihor Radchenko
2022-07-28 13:17 ` [PATCH] Add new entity \-- serving as markup separator/escape symbol Ihor Radchenko
2022-07-29 0:32 8% ` Juan Manuel Macías
2022-07-12 17:18 missing a character / font in agenda? Daniel Ortmann
2022-07-12 17:58 ` Juan Manuel Macías
2022-07-12 18:45 ` [External] : " Daniel Ortmann
2022-07-12 19:52 9% ` Juan Manuel Macías
2021-10-06 15:18 how to export to odt with 11 or 10 pt fonts? Default font setting Uwe Brauer
2021-10-07 11:24 9% ` Juan Manuel Macías
2021-10-07 12:28 ` Uwe Brauer
2021-10-07 12:58 9% ` Juan Manuel Macías
2021-12-16 5:16 format/fill of text in a cell in tables George Michaelson
2021-12-16 9:45 ` Ihor Radchenko
2021-12-16 21:51 ` Tim Cross
2021-12-18 7:27 ` Uwe Brauer
2021-12-18 11:09 8% ` 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-01-21 17:47 9% ` 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 ` Juan Manuel Macías
2021-06-06 22:34 ` Juan Manuel Macías
2021-06-08 0:24 9% ` [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.) Juan Manuel Macías
2014-03-04 13:11 [RFC] Creole-style / Support for **emphasis**__within__**a word** Jambunathan K
2014-03-22 14:05 ` Nicolas Goaziou
2014-03-23 2:59 ` Jambunathan K
2022-01-24 10:50 ` [O] " Vincent Belaïche
2022-01-24 12:09 9% ` Juan Manuel Macías
2022-01-24 12:32 ` Vincent Belaïche
2022-01-25 10:55 ` Nicolas Goaziou
2022-01-25 17:18 ` Vincent Belaïche
2022-01-25 17:30 9% ` 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-05-23 21:06 9% ` Juan Manuel Macías
2022-06-19 12:47 ` Juan Manuel Macías
2022-06-19 19:30 ` Christian Moe
2022-06-19 20:15 9% ` Juan Manuel Macías
2021-04-05 20:48 Choosing a LaTeX Compiler (my predilection for LuaTeX) Juan Manuel Macías
2021-04-05 21:17 ` Dr. Arne Babenhauserheide
2021-04-05 21:36 9% ` Juan Manuel Macías
2021-04-06 19:03 ` physiculus
2021-04-06 19:13 9% ` 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-02 13:10 ` Ihor Radchenko
2023-10-02 14:55 9% ` Juan Manuel Macías
2021-07-26 9:25 Multilingual quotes inside paragraphs Juan Manuel Macías
2021-07-28 12:13 ` Maxim Nikulin
2021-07-28 13:49 8% ` Juan Manuel Macías
2022-07-13 10:49 [tip/offtopic] A function to describe the characters of a word at point Juan Manuel Macías
2022-07-14 15:42 ` Marcin Borkowski
2022-07-15 0:56 8% ` Juan Manuel Macías
2021-06-12 9:15 Write Markdown in Org mode leo
2021-06-12 12:35 9% ` Juan Manuel Macías
2021-11-28 19:46 "Orgdown", the new name for the syntax of Org-mode Karl Voit
2021-11-28 22:25 8% ` Juan Manuel Macías
2021-11-29 5:41 ` Marcin Borkowski
2021-11-29 12:18 9% ` Juan Manuel Macías
2021-11-28 22:42 ` Tim Cross
2021-11-29 13:19 ` Karl Voit
2021-11-29 18:27 ` M. ‘quintus’ Gülker
2021-11-30 20:44 ` Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode) Karl Voit
2021-12-01 0:41 ` Tom Gillespie
2021-12-01 3:28 9% ` Orgdown: negative feedback & attempt of a root-cause analysis Juan Manuel Macías
2021-03-17 20:29 Syntax Proposal: Multi-line Table Cells/Text Wrapping Atlas Cove
2021-03-17 22:07 9% ` Juan Manuel Macías
2021-03-18 14:26 ` Timothy
2021-03-18 14:31 ` Atlas Cove
2021-03-18 21:58 ` Tim Cross
2021-03-18 22:41 ` Juan Manuel Macías
2021-03-19 8:08 ` tomas
2021-03-19 8:44 ` Juan Manuel Macías
2021-03-19 8:53 ` tomas
2021-03-19 9:22 9% ` Juan Manuel Macías
2021-03-19 10:14 ` tomas
2021-03-19 10:53 9% ` Juan Manuel Macías
2021-12-23 16:11 text after sub headings? Robert Nikander
2021-12-23 20:27 ` Juan Manuel Macías
2021-12-24 16:51 ` Max Nikulin
2021-12-24 20:17 ` Juan Manuel Macías
2021-12-25 13:15 ` Max Nikulin
2021-12-26 9:17 8% ` 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 ` Juan Manuel Macías
2021-06-19 18:28 ` [External Email] " Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 19:32 9% ` Juan Manuel Macías
2024-01-02 23:46 [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export Juan Manuel Macías
2024-01-13 15:08 ` Ihor Radchenko
2024-01-13 16:05 ` Juan Manuel Macías
2024-01-13 18:28 ` Ihor Radchenko
2024-01-13 20:22 ` Juan Manuel Macías
2024-01-14 12:33 ` Ihor Radchenko
2024-01-14 21:58 ` Juan Manuel Macías
2024-01-16 14:09 ` Ihor Radchenko
2024-01-16 19:33 8% ` Juan Manuel Macías
2024-01-17 13:00 ` Ihor Radchenko
2024-01-17 17:50 ` Juan Manuel Macías
2024-01-18 13:05 ` Ihor Radchenko
2024-01-19 17:28 ` Juan Manuel Macías
2024-01-20 12:34 ` Ihor Radchenko
2024-01-20 13:22 9% ` Juan Manuel Macías
2024-01-20 13:46 ` Ihor Radchenko
2024-01-20 15:41 9% ` Juan Manuel Macías
2024-01-20 18:47 ` Ihor Radchenko
2024-01-20 20:27 9% ` Juan Manuel Macías
2021-03-02 20:07 Org mode links: Open a PDF file at a given page and highlight a given string Rodrigo Morales
2021-03-03 2:31 9% ` Juan Manuel Macías
2021-03-03 14:51 ` Maxim Nikulin
2021-03-03 16:11 9% ` Juan Manuel Macías
2022-06-17 12:47 Utility of description lists Cletip Cletip
2022-06-17 14:24 9% ` Juan Manuel Macías
2021-12-05 7:35 Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal Ihor Radchenko
2021-12-05 9:16 9% ` Juan Manuel Macías
2021-12-05 10:24 ` Ihor Radchenko
2021-12-05 11:08 9% ` Juan Manuel Macías
2021-12-05 12:08 ` Ihor Radchenko
2021-12-05 18:59 ` Juan Manuel Macías
2021-12-05 23:24 ` Russell Adams
2021-12-06 5:57 ` Juan Manuel Macías
2021-12-06 6:02 ` Timothy
2021-12-06 7:24 9% ` Juan Manuel Macías
2021-12-06 10:04 ` Greg Minshall
2021-12-06 14:59 9% ` Juan Manuel Macías
2021-11-14 17:08 Should be possible to export list items emphasized by default? Ypo
2021-11-17 13:33 9% ` Juan Manuel Macías
2021-01-23 11:03 [Tip] Export a bibliography to HTML with bibLaTeX and make4ht Juan Manuel Macías
2021-01-24 11:37 ` Gustavo Barros
2021-01-24 13:00 ` Gustavo Barros
2021-01-24 19:20 ` Juan Manuel Macías
2021-01-24 22:44 ` Gustavo Barros
2021-01-25 17:46 9% ` Juan Manuel Macías
2022-05-26 10:01 [tip] org-publish to work with (very) large books Juan Manuel Macías
2022-05-26 12:46 ` Christian Moe
2022-05-26 13:11 ` Ihor Radchenko
2022-05-26 13:48 8% ` Juan Manuel Macías
2022-06-10 18:28 [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments' Juan Manuel Macías
2022-06-12 19:18 ` Rudolf Adamkovič
2022-06-12 19:55 9% ` Juan Manuel Macías
2022-06-11 5:39 ` Ihor Radchenko
2022-06-11 11:20 9% ` Juan Manuel Macías
2022-06-14 3:58 ` Ihor Radchenko
2022-06-14 11:11 ` Juan Manuel Macías
2022-06-14 11:55 ` Ihor Radchenko
2022-06-15 10:30 9% ` Juan Manuel Macías
2022-01-24 15:59 Missing the second '}' Sharon Kimble
2022-01-24 16:46 9% ` 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 12:53 ` Sebastian P. Luque
2021-12-27 13:28 8% ` 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 9% ` Juan Manuel Macías
2022-10-30 13:10 ` Uwe Brauer
2022-10-30 13:56 9% ` Juan Manuel Macías
2022-10-30 17:16 ` Uwe Brauer
2022-10-30 18:17 9% ` Juan Manuel Macías
2022-10-30 18:48 ` Uwe Brauer
2022-10-30 19:04 9% ` Juan Manuel Macías
2022-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-04 12:16 ` Max Nikulin
2022-08-05 17:14 9% ` Juan Manuel Macías
2021-10-04 14:27 [patch] ox-html.el: add html attribute (verse numbers) to verse blocks Juan Manuel Macías
2022-05-30 5:10 ` Ihor Radchenko
2022-05-30 15:36 9% ` Juan Manuel Macías
2022-01-17 14:14 latex block tikz to svg Edouard Debry
2022-01-17 16:01 9% ` Juan Manuel Macías
2021-06-07 13:09 org-critical-edition (a package for philologists and classicists) Juan Manuel Macías
2021-06-14 8:50 ` Christian Moe
2021-06-15 12:44 9% ` Juan Manuel Macías
2020-09-08 5:39 idea for capture anywhere in x Maxim Nikulin
2020-09-08 22:40 ` Samuel Wales
2020-09-09 4:52 ` Maxim Nikulin
2020-09-10 14:23 ` Maxim Nikulin
2020-09-12 8:48 ` Nick Econopouly
2022-06-10 2:35 ` Samuel Wales
2022-10-09 14:47 ` Jean Louis
2022-10-09 16:40 ` Max Nikulin
2022-10-09 17:08 ` Jean Louis
2022-10-10 17:16 ` Max Nikulin
2022-10-10 22:06 ` Jean Louis
2022-10-11 9:11 9% ` Juan Manuel Macías
2022-10-15 21:35 [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 ` 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 ` Juan Manuel Macías
2022-10-19 17:07 ` Max Nikulin
2022-10-20 16:55 ` Juan Manuel Macías
2022-10-21 3:34 ` Ihor Radchenko
2022-10-21 16:38 ` Max Nikulin
2022-10-21 19:32 9% ` Juan Manuel Macías
2021-05-02 20:20 About multilingual documents Juan Manuel Macías
2021-05-03 6:58 ` Aleksandar Dimitrov
2021-05-03 20:33 9% ` Juan Manuel Macías
2021-09-26 12:24 [BUG] Conflict between org-emphasis and org-latex Léo Ackermann
2021-09-26 12:57 ` Juan Manuel Macías
2021-09-26 16:57 ` Léo Ackermann
2021-09-26 18:29 9% ` 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 ` Juan Manuel Macías
2022-09-28 3:15 ` Ihor Radchenko
2022-09-28 7:50 9% ` Explicit page breaks (was: Create in Org a bilingual book with facing pages) Juan Manuel Macías
2022-01-13 18:27 Playing down the text in org-mode fatiparty--- via General discussions about Org-mode.
[not found] ` <87bl0feahc.fsf@posteo.net-MtJnHBm----2>
2022-01-13 19:15 ` fatiparty--- via General discussions about Org-mode.
2022-01-13 19:42 ` Juan Manuel Macías
2022-01-13 19:53 ` fatiparty--- via General discussions about Org-mode.
[not found] ` <87iluncrr6.fsf@posteo.net-MtK5wx2----2>
2022-01-13 20:53 ` fatiparty--- via General discussions about Org-mode.
2022-01-13 21:39 ` Juan Manuel Macías
[not found] ` <874k66irh4.fsf@ucl.ac.uk-MtMyJM6----2>
2022-01-14 13:03 ` fatiparty--- via General discussions about Org-mode.
[not found] ` <87o84efnqk.fsf@ucl.ac.uk-MtNobqT----2>
2022-01-14 13:44 ` fatiparty--- via General discussions about Org-mode.
2022-01-14 14:13 ` Eric S Fraga
2022-01-14 19:27 ` fatiparty--- via General discussions about Org-mode.
2022-01-14 20:00 9% ` Juan Manuel Macías
2022-01-13 20:20 9% ` Juan Manuel Macías
2021-08-14 15:06 Smart quotes for Greek (questions for a possible patch) Juan Manuel Macías
2021-08-15 21:28 ` mvar
2021-08-16 13:57 8% ` Juan Manuel Macías
2024-03-01 20:34 Experimental public branch for inline special blocks Juan Manuel Macías
2024-03-03 20:29 9% ` Juan Manuel Macías
2022-02-24 19:12 ConTeXt exporter makes me happy juh
2022-02-24 19:58 9% ` Juan Manuel Macías
2021-02-15 17:37 'false' list item Juan Manuel Macías
2021-02-21 6:56 ` Kyle Meyer
2021-02-21 19:33 ` Juan Manuel Macías
2021-02-21 19:40 ` Diego Zamboni
2021-02-21 21:27 ` Samuel Wales
2021-02-21 22:31 ` Tim Cross
2021-02-22 0:21 9% ` Juan Manuel Macías
2021-11-30 16:28 how to export red colored TeX to latex Uwe Brauer
2021-11-30 16:56 9% ` Juan Manuel Macías
2022-11-10 6:11 [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)] Ihor Radchenko
2022-11-10 12:40 9% ` Juan Manuel Macías
2020-12-27 13:02 A way to avoid unwanted new lines when using paragraph quotes? Kashyap Chamarthy
2020-12-27 15:52 ` Diego Zamboni
2020-12-27 18:33 ` Kashyap Chamarthy
2020-12-27 19:17 9% ` Juan Manuel Macías
2021-01-22 9:20 Dealing with wide labels in description environment Loris Bennett
2021-01-22 11:20 9% ` Juan Manuel Macías
2020-12-28 13:38 Org to ConTeXt exporter? Juan Manuel Macías
2020-12-28 15:04 ` Marcin Borkowski
2020-12-28 16:23 ` Diego Zamboni
2020-12-28 18:03 ` Juan Manuel Macías
2020-12-28 20:03 ` Marcin Borkowski
2020-12-29 16:05 9% ` Juan Manuel Macías
2021-09-27 12:07 LaTeX export: grffile is a stub package meedstrom
2021-09-27 17:00 9% ` Juan Manuel Macías
2022-01-15 18:04 org-->html text between @ should be red Uwe Brauer
2022-01-15 18:21 ` Juan Manuel Macías
2022-01-15 19:39 ` Uwe Brauer
2022-01-15 19:59 ` Juan Manuel Macías
2022-01-15 20:24 ` Uwe Brauer
2022-01-15 20:58 9% ` Juan Manuel Macías
2021-07-10 13:42 org-mode export to (latex) PDF Jean-Christophe Helary
2021-07-10 18:43 ` Jonathan McHugh
2021-07-10 19:24 9% ` Juan Manuel Macías
2021-07-10 13:52 ` Juan Manuel Macías
2021-07-10 16:13 ` Maxim Nikulin
2021-07-10 16:44 ` Stefan Nobis
2021-07-13 16:53 ` Maxim Nikulin
2021-07-13 17:53 8% ` Juan Manuel Macías
2021-07-14 6:44 ` Stefan Nobis
2021-07-14 17:30 ` Maxim Nikulin
2021-07-14 19:29 9% ` Juan Manuel Macías
2021-10-03 15:28 [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Juan Manuel Macías
2022-07-10 9:25 ` Ihor Radchenko
2022-07-14 12:34 ` Juan Manuel Macías
2022-07-17 9:55 ` Ihor Radchenko
2022-07-19 15:01 ` Juan Manuel Macías
2022-07-19 17:01 ` Max Nikulin
2022-07-19 19:31 ` Juan Manuel Macías
2022-07-20 16:12 ` Max Nikulin
2022-07-20 21:30 9% ` 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 9% ` Juan Manuel Macías
2022-07-22 14:07 ` Juan Manuel Macías
2022-07-23 15:19 ` Max Nikulin
2022-07-23 17:15 8% ` Improvements in the default LaTeX preamble (was: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists) Juan Manuel Macías
2022-07-14 15:12 ` [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Max Nikulin
2022-07-14 15:53 9% ` Juan Manuel Macías
2022-02-26 14:33 including one double quote in an anonymous footnote? Greg Minshall
2022-02-26 14:47 ` Juan Manuel Macías
2022-02-26 15:00 ` Greg Minshall
2022-02-26 19:20 9% ` Juan Manuel Macías
2023-03-21 3:36 org-ctags land grab Nick Dokos
2023-08-08 8:48 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? Ihor Radchenko
2023-08-08 13:29 ` Bastien Guerry
2023-08-11 9:44 ` 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 9% ` [DISCUSSION] Re-design of inlinetasks Juan Manuel Macías
2023-08-26 10:58 ` Ihor Radchenko
2023-08-26 11:42 ` Juan Manuel Macías
2023-08-26 12:33 ` Ihor Radchenko
2023-08-26 14:21 9% ` Juan Manuel Macías
2021-01-29 16:03 org-attach-git don't automatically commit changes Juan Manuel Macías
2021-01-30 5:10 ` Ihor Radchenko
2021-01-30 13:38 9% ` Juan Manuel Macías
2021-01-31 3:33 ` Ihor Radchenko
2021-01-31 10:29 9% ` Juan Manuel Macías
2022-05-13 16:37 simple request letter - help Andrés Ramírez
2022-05-13 17:04 ` Juan Manuel Macías
2022-05-13 17:19 ` andrés ramírez
2022-05-13 18:22 8% ` Juan Manuel Macías
2022-05-13 19:06 ` andrés ramírez
2022-05-13 20:30 9% ` Juan Manuel Macías
2022-01-06 17:00 Way to mark contents of an Org special block as verbatim? Kaushal Modi
2022-01-06 18:27 9% ` Juan Manuel Macías
2022-06-08 9:59 Org-attach for a directory Cletip Cletip
2022-06-08 10:32 9% ` Juan Manuel Macías
[not found] ` <CAPHku6O3RojzhaSu3d2pWfnE8x7N_9WAfjCupHyKcxNyD-i=ew@mail.gmail.com>
2022-06-09 10:11 8% ` Juan Manuel Macías
2021-05-28 2:54 Smart quotes not working correctly with single quotes Andreas Gösele
2021-05-28 10:10 ` Juan Manuel Macías
2021-05-28 15:42 ` Andreas Gösele
2021-05-28 17:02 9% ` Juan Manuel Macías
2021-07-05 19:44 convert subtree or nested list to table Matt Price
2021-07-05 20:01 ` Juan Manuel Macías
[not found] ` <CAN_Dec8iqKS+3qvjkYvQxovegnEzqR_rra0Q-ZA9baPz1mXDAA@mail.gmail.com>
2021-07-06 12:56 8% ` Juan Manuel Macías
2021-10-01 15:59 export dispatch → change the default "Contents" string Jean-Christophe Helary
2021-10-01 16:35 9% ` Juan Manuel Macías
2022-03-05 15:40 Filter for HTML footnotes? M. ‘quintus’ Gülker
2022-03-06 4:03 9% ` Juan Manuel Macías
2021-03-31 9:40 How to expand macro in LaTeX export? How to use different options per export type? Jean Louis
2021-04-03 21:57 9% ` Juan Manuel Macías
2022-07-23 13:44 BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Kai von Fintel
2022-07-23 13:59 ` Ihor Radchenko
2022-07-23 14:07 ` Kai von Fintel
2022-07-23 14:22 ` Ihor Radchenko
2022-07-23 14:39 ` Kai von Fintel
2022-07-23 14:50 ` Ihor Radchenko
2022-07-23 15:53 9% ` Juan Manuel Macías
2022-07-24 7:15 ` Ihor Radchenko
2022-07-24 11:29 9% ` Juan Manuel Macías
2022-07-26 11:58 ` Ihor Radchenko
2022-07-26 16:19 9% ` Juan Manuel Macías
2023-08-30 8:25 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 ` Juan Manuel Macías
2023-09-06 9:29 ` Ihor Radchenko
2023-09-06 14:58 8% ` Juan Manuel Macías
2023-09-07 10:22 ` Ihor Radchenko
2023-09-07 12:04 9% ` 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 15:51 ` Max Nikulin
2021-12-02 18:11 ` Tom Gillespie
2021-12-02 19:09 9% ` Juan Manuel Macías
2021-12-04 13:07 ` Org-syntax: emphasis and not English punctuation Max Nikulin
2021-12-04 16:42 9% ` Juan Manuel Macías
2021-12-02 19:03 ` Org-syntax: Intra-word markup Nicolas Goaziou
2021-12-02 19:34 9% ` Juan Manuel Macías
2021-12-02 23:05 ` Nicolas Goaziou
2021-12-02 23:24 9% ` Juan Manuel Macías
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-04 21:16 9% ` Juan Manuel Macías
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-08 13:09 ` Max Nikulin
2021-12-08 23:19 9% ` Juan Manuel Macías
2021-12-04 19:04 ` Org-syntax: Intra-word markup Timothy
2021-12-04 21:48 ` Tom Gillespie
2022-01-28 14:52 ` Max Nikulin
2022-01-29 3:13 ` Ihor Radchenko
2022-01-29 13:05 9% ` Juan Manuel Macías
2022-02-02 15:28 ` Max Nikulin
2022-02-02 20:01 9% ` Juan Manuel Macías
2021-12-02 11:18 ` Ihor Radchenko
2021-12-02 11:30 ` Juan Manuel Macías
2021-12-02 11:42 ` Marco Wahl
2021-12-02 11:50 ` Denis Maier
2021-12-02 12:10 ` Ihor Radchenko
2021-12-02 12:40 ` Denis Maier
2021-12-02 12:54 ` Ihor Radchenko
2021-12-02 13:14 9% ` Juan Manuel Macías
2022-01-28 12:12 ` [PATCH] Intra-word markup: \relax Max Nikulin
2022-01-28 13:13 9% ` Juan Manuel Macías
2022-10-09 20:15 idea for capture anywhere in x Ypo
2022-10-12 9:34 ` Ihor Radchenko
2022-10-12 10:43 ` Ypo
2022-10-12 14:22 8% ` Juan Manuel Macías
2020-12-25 16:02 [tip] Export subfigures to LaTeX (and HTML) Juan Manuel Macías
2020-12-28 18:03 ` John Kitchin
2020-12-29 15:00 9% ` Juan Manuel Macías
2020-12-17 17:23 [PATCH] A proposal to add LaTeX attributes to verse blocks Juan Manuel Macías
2021-01-03 10:25 ` TEC
2021-01-03 13:07 ` Juan Manuel Macías
2021-01-03 13:08 ` TEC
2021-01-07 18:52 ` Juan Manuel Macías
2021-05-01 10:58 ` Bastien
[not found] ` <87tunlxws3.fsf@ucl.ac.uk>
2021-05-02 11:09 9% ` Juan Manuel Macías
2022-06-24 1:45 Org and Hyperbole Robert Weiner
2022-06-24 13:52 ` Juan Manuel Macías
2022-06-24 22:06 ` Robert Weiner
2022-06-25 14:32 9% ` Juan Manuel Macías
2022-06-20 14:03 Juan Manuel Macías
2022-06-21 3:08 ` David Masterson
2022-06-22 10:37 9% ` 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 8% ` Juan Manuel Macías
2021-02-01 9:10 http links translated to html : target "_blank" Uwe Brauer
2021-02-01 11:03 9% ` Juan Manuel Macías
2022-10-06 13:20 Interest in an Org video meetup? Russell Adams
2022-10-06 20:09 ` Juan Manuel Macías
2022-10-07 1:43 ` Ihor Radchenko
2022-10-07 1:47 ` Russell Adams
2022-10-07 10:37 ` 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-12 9:26 ` Ihor Radchenko
2022-10-12 10:22 9% ` Juan Manuel Macías
2021-05-16 15:31 [Question] Custom parse tree filter Juan Manuel Macías
2021-05-16 15:59 ` Nicolas Goaziou
2021-05-17 12:20 8% ` Juan Manuel Macías
2021-03-04 15:38 Bug: alphabetical lists will not show up as such in LaTeX export [9.3.6 (9.3.6-71-g7684b5-elpaplus @ /home/qqwy/.emacs.d/elpa/org-plus-contrib-20200518/)] Qqwy/Wiebe-Marten
2021-03-05 12:01 9% ` 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).