* Re: [PATCH] Startup option to separate macros arguments with an alternative string
@ 2021-04-21 16:01 4% ` Juan Manuel Macías
2021-04-22 12:55 5% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-21 16:01 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hello again.
I forgot to answer this question on your previous message, sorry...
Nicolas Goaziou writes:
> That being said, we can discuss syntax that is not depending upon some
> variable. For example macro names are written with a limited set of
> characters (alphanumeric, dash, underscore). We might allow the optional
> argument separator to be located right before the opening parenthesis,
> e.g.,
>
> {{{macroname@(latin@Lorem ipsum dolor sit amet, ...)}}}
> {{{macroname|(latin|Lorem ipsum dolor sit amet, ...)}}}
I think it's a very interesting idea. I've made this sketch (at least
as a proof of concept), what do you think of the approach?
Example (and code below):
#+macro: foo (eval (format "%s and %s" $1 $2))
{{{foo(xxx,zzz\, yyy)}}}
{{{foo|(xxx|zzz, aaa)}}}
{{{foo@(xxx@zzz, sss)}}}
{{{foo|(xxx|zzz\| aaa)}}}
{{{foo@(xxx@zzz\@ sss)}}}
#+begin_src emacs-lisp
(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
`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" (format "%s" sep)))))
s nil t)
"\000"))
(defun org-element-macro-parser ()
"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
`: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_]*\\)\\([^a-zA-Z]*[^-a-zA-Z0-9_]*\\)\\((\\([^\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))
(args (pcase (match-string-no-properties 4)
(`nil nil)
(a (org-macro-extract-arguments
(if (not (equal (match-string-no-properties 2) ""))
(match-string-no-properties 2)
",")
(replace-regexp-in-string
"[ \t\r\n]+" " " (org-trim a)))))))
(list 'macro
(list :key key
:value value
:args args
:begin begin
:end end
:post-blank post-blank))))))
(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
`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" (format "%s" sep)))))
s nil t)
"\000"))
#+end_src
^ permalink raw reply [relevance 4%]
* Re: [PATCH] Startup option to separate macros arguments with an alternative string
2021-04-21 16:01 4% ` Juan Manuel Macías
@ 2021-04-22 12:55 5% ` Nicolas Goaziou
2021-04-22 13:46 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-04-22 12:55 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I think it's a very interesting idea. I've made this sketch (at least
> as a proof of concept), what do you think of the approach?
I think there are a few things to fix. For example, the separator may
need to be stored in the properties of the macro. Otherwise,
interpreting data back would return to comma-separated arguments, which
may not be desirable, although correct.
Also, I would limit separator to a single character. You also need to
exclude space characters.
> Example (and code below):
>
> #+macro: foo (eval (format "%s and %s" $1 $2))
>
> {{{foo(xxx,zzz\, yyy)}}}
>
> {{{foo|(xxx|zzz, aaa)}}}
>
> {{{foo@(xxx@zzz, sss)}}}
>
> {{{foo|(xxx|zzz\| aaa)}}}
>
> {{{foo@(xxx@zzz\@ sss)}}}
This change will need to be tested extensively in "test-org-element.el"
and "test-org-macro.el".
However, as a start, I suggest starting a new thread about a suggested
change in the syntax, with a clear title, examples, and code. Then we
can leave time for users to react to it.
Do you want to take care of it?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 5%]
* Re: [PATCH] Startup option to separate macros arguments with an alternative string
2021-04-22 12:55 5% ` Nicolas Goaziou
@ 2021-04-22 13:46 10% ` Juan Manuel Macías
2021-04-25 3:46 6% ` Timothy
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-22 13:46 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hi Nicolas,
Thank you very much for your suggestions.
Nicolas Goaziou writes:
> This change will need to be tested extensively in "test-org-element.el"
> and "test-org-macro.el".
>
> However, as a start, I suggest starting a new thread about a suggested
> change in the syntax, with a clear title, examples, and code. Then we
> can leave time for users to react to it.
>
> Do you want to take care of it?
Ok, I agree. Next week I will start a new thread for submit this new
proposal.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-24 14:41 5% ` Maxim Nikulin
0 siblings, 0 replies; 200+ results
From: Maxim Nikulin @ 2021-04-24 14:41 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Nicolas Goaziou
On 21/04/2021 22:45, Juan Manuel Macías wrote:
>
> 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
I am afraid, there is no easy way to take into account emphasis. Each
item have to be split into logical units and locale-aware multilevel
comparison should be applied to each unit separately. E.g. for
description list, only term should be compared at first to properly
order emphasized items, it does not matter if description starts from
"a" or from "z". Simple `string-collate-lessp' for whole item uses
further levels only strings are considered identical on previous levels.
I had an idea to augment sort keys with some text properties for custom
string comparator, but I decided that such complications would not
ensure reliable sort for all possible cases.
- A :: B
- /A/ :: C
- *A* :: A
However `org-sort-remove invisible' still has some room for improvements
(it is not mandatory in my opinion). I have realized it reading the
thread on title representation for HTML export
https://orgmode.org/list/87h7jy4ebe.fsf@nicolasgoaziou.fr/
- <<target>>A
- <<<radio>>>
- B
^ permalink raw reply [relevance 5%]
* Re: [PATCH] Startup option to separate macros arguments with an alternative string
2021-04-22 13:46 10% ` Juan Manuel Macías
@ 2021-04-25 3:46 6% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:46 UTC (permalink / raw)
To: emacs-orgmode
As you have said you'll start a new thread for your revised proposal,
I'll mark this as closed on updates.orgmode.org via the X-Woof-Patch
header.
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ok, I agree. Next week I will start a new thread for submit this new
> proposal.
>
> Best regards,
>
> Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: [tip] search this mailing list with helm-surfraw
@ 2021-04-25 5:00 7% ` Bastien
2021-04-27 20:20 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Bastien @ 2021-04-25 5:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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:
Neat!
You might want to write another one for the public-inbox archive:
E.g. https://orgmode.org/list/?q=Juan+Manuel+Mac%C3%ADas
^ permalink raw reply [relevance 7%]
* Re: [tip] search this mailing list with helm-surfraw
2021-04-25 5:00 7% ` Bastien
@ 2021-04-27 20:20 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-27 20:20 UTC (permalink / raw)
To: Bastien; +Cc: orgmode
Hi Bastien,
Bastien writes:
> Neat!
>
> You might want to write another one for the public-inbox archive:
>
> E.g. https://orgmode.org/list/?q=Juan+Manuel+Mac%C3%ADas
I was unaware that searches in the public-box archive are faster...
Thank you very much for the advice :-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [patch] to allow org-attach-git to handle individual repositories
@ 2021-04-28 3:57 6% ` Bastien
2021-04-28 13:42 10% ` Juan Manuel Macías
2021-05-15 14:08 6% ` Bastien
1 sibling, 1 reply; 200+ results
From: Bastien @ 2021-04-28 3:57 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Ihor Radchenko
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I would like to propose and discuss this patch for org-attach-git,
> following a series of comments and suggestions from Ihor Radchenko in
> this thread:
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00483.html
thanks for the patch and sorry for the slow reply.
It looks good but it is significative enough to require you to sign
the FSF copyright assignment. If you're willing to go through this
(which will secure future contributions too), please see:
https://orgmode.org/request-assign-future.txt
Thanks!
^ permalink raw reply [relevance 6%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-28 5:46 6% ` Bastien
2021-04-28 6:37 0% ` Nicolas Goaziou
1 sibling, 1 reply; 200+ results
From: Bastien @ 2021-04-28 5:46 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Nicolas Goaziou
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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...
applied in the maint branch as commit 5be650714.
The patch was missing a proper changelog entry: please see
https://orgmode.org/worg/org-contribute.html#commit-messages
for future patches.
Thanks!
^ permalink raw reply [relevance 6%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-28 5:46 6% ` Bastien
@ 2021-04-28 6:37 0% ` Nicolas Goaziou
0 siblings, 0 replies; 200+ results
From: Nicolas Goaziou @ 2021-04-28 6:37 UTC (permalink / raw)
To: Bastien; +Cc: Juan Manuel Macías, orgmode
Hello,
Bastien <bzg@gnu.org> writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> 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...
>
> applied in the maint branch as commit 5be650714.
Unfortunately, this is not a proper fix for the problem, as discussed in
the thread.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 0%]
* Re: [patch] to allow org-attach-git to handle individual repositories
2021-04-28 3:57 6% ` Bastien
@ 2021-04-28 13:42 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-28 13:42 UTC (permalink / raw)
To: Bastien; +Cc: orgmode
Hi Bastien,
Bastien writes:
> It looks good but it is significative enough to require you to sign
> the FSF copyright assignment. If you're willing to go through this
> (which will secure future contributions too), please see:
Thanks for the advice. I just signed and sent the FSF copyright
assignment.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [PATCH] Possibility of using alternative separators in macros
@ 2021-04-30 13:26 6% Juan Manuel Macías
2021-05-11 11:01 5% ` Eric S Fraga
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-30 13:26 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]
Hi all,
I would like to propose (patch attached) the possibility of using an
alternate character for separate arguments in replacement macros,
following a suggestion from Nicolas Goaziou in this (closed) thread:
https://orgmode.org/list/87o8ead42u.fsf@nicolasgoaziou.fr/
The idea would be to explicitly indicate the separator just before the
parentheses. The allowed characters are any character other than a
letter, a number, a space, a dash, a low line or a parenthesis.
A new property `:sep' is added to `org-element-macro-parser', whose
default value is a comma.
Example of use. Suppose we define this macro:
#+MACRO: foo (eval (format "%s and %s" $1 $2))
Under normal conditions, the expected separator will be the comma:
{{{foo(x,z\, y)}}}
=> x and z, y
But we can also do this:
{{{foo@(x@z, y \@)}}}
=> x and z, y @
I think sometimes it may be preferable to separate the arguments by an
alternative character. For example, let's imagine we define a macro
(named 'lg') for LaTeX export, which admits two arguments, exactly the
same args as the Babel (LaTeX) macro \foreignlanguage{lang}{short-text}:
{{{lg(lang,short-text)}}}.
It would be much more comfortable something like:
{{{lg|(latin|trado, tradidi, traditur)}}}
instead of having to escape commas in:
{{{lg(latin,trado\, tradidi\, traditur)}}}
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Alternative-args-separator-for-replacement-macros.patch --]
[-- Type: text/x-patch, Size: 2967 bytes --]
From 400d5779508fd7206a353bdb444c3cba382b8f01 Mon Sep 17 00:00:00 2001
From: juanmanuel <maciaschain@posteo.net>
Date: Fri, 30 Apr 2021 14:45:54 +0200
Subject: [PATCH] Alternative args separator for replacement macros
---
lisp/org-element.el | 9 +++++++--
lisp/org-macro.el | 9 +++++----
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index a675bf512..34a9b880a 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]*?\\))\\)?}}}")
+ (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 6%]
* Re: How to create a macro that inserts multiline text with :B_ignoreheading: tag?
@ 2021-04-30 20:40 10% ` Juan Manuel Macías
2021-04-30 23:40 3% ` Richard Stanton
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-30 20:40 UTC (permalink / raw)
To: Richard Stanton; +Cc: orgmode
Hi Richard,
Richard Stanton <rhstanton@berkeley.edu> writes:
> I’d like to define a macro called, say, articletext, to insert this
> header into my document before exporting to LaTeX, so the org file
> would look something like this:
>
> {{{article text}}}
> This text appears only in the article version.
Macro definitions do not allow spaces.
You can try something like:
#+MACRO: article_text (eval (concat "*** More explanation coming" "\s" ":B_ignoreheading:\n:PROPERTIES:\n:BEAMER_env: ignoreheading\n:END:"))
{{{article_text}}}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: How to create a macro that inserts multiline text with :B_ignoreheading: tag?
2021-04-30 20:40 10% ` Juan Manuel Macías
@ 2021-04-30 23:40 3% ` Richard Stanton
0 siblings, 0 replies; 200+ results
From: Richard Stanton @ 2021-04-30 23:40 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
That works. Thanks Juan Manuel!
> On Apr 30, 2021, at 1:40 PM, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Hi Richard,
>
> Richard Stanton <rhstanton@berkeley.edu> writes:
>
>> I’d like to define a macro called, say, articletext, to insert this
>> header into my document before exporting to LaTeX, so the org file
>> would look something like this:
>>
>> {{{article text}}}
>> This text appears only in the article version.
>
> Macro definitions do not allow spaces.
>
> You can try something like:
>
> #+MACRO: article_text (eval (concat "*** More explanation coming" "\s" ":B_ignoreheading:\n:PROPERTIES:\n:BEAMER_env: ignoreheading\n:END:"))
>
> {{{article_text}}}
>
> Best regards,
>
> Juan Manuel
^ permalink raw reply [relevance 3%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
@ 2021-05-01 10:58 6% ` Bastien
2021-05-01 11:46 10% ` Juan Manuel Macías
` (2 more replies)
2021-05-01 10:58 6% ` Timothy
1 sibling, 3 replies; 200+ results
From: Bastien @ 2021-05-01 10:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Eric Fraga, orgmode, TEC
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I am attaching a new version of my patch for adding LaTeX attributes to
> verse blocks. Following the kind suggestions from Timothy, I have also
> documented this new features that I propose. I don't know if I have done
> it correctly and in the right place...
thanks a lot -- we need to wait for the FSF copyright assignment
process to be finished in order to accept this patch.
I'm copying Eric, a poweruser of the LaTeX backend, so that he can
perhaps comment on the general usefulness of this addition.
The patch lacks a commit message - see this explanations:
https://orgmode.org/worg/org-contribute.html#commit-messages
Let us know if you need more directions and how to produce a patch
that we can more easily apply.
Thanks!
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-05-01 10:58 6% ` Bastien
@ 2021-05-01 10:58 6% ` Timothy
1 sibling, 0 replies; 200+ results
From: Timothy @ 2021-05-01 10:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
Sorry it's still taking a while for your patch to be looked at.
Assuming it does get merged, it would be good to check if you'd be
willing to write a manual entry to accompany this (in a separate patch
works).
Thanks again for the patch,
Timothy.
Juan Manuel Macías <maciaschain@posteo.net> writes:
^ permalink raw reply [relevance 6%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-05-01 10:58 6% ` Bastien
@ 2021-05-01 11:46 10% ` Juan Manuel Macías
[not found] ` <87tunlxws3.fsf@ucl.ac.uk>
2021-05-08 7:31 6% ` Juan Manuel Macías
2 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-01 11:46 UTC (permalink / raw)
To: Bastien; +Cc: orgmode
Hi Bastien,
Thank you very much again for your kind suggestions.
Bastien writes:
> I'm copying Eric, a poweruser of the LaTeX backend, so that he can
> perhaps comment on the general usefulness of this addition.
I think these additions (line numbers, optical centering of the poem,
etc.) can be useful (IMHO) for the correct representation of poetry
(generally in Humanities), since the verse.sty package is a sort of
'unofficial' replacement for the standard LaTeX verse environment, which
has certain limitations.
> The patch lacks a commit message - see this explanations:
> https://orgmode.org/worg/org-contribute.html#commit-messages
Sorry again for not including a commit message. If the patch it is
finally accepted, I can submit a new version that includes a commit
message (and a few minor fixes I made to the code).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] Possibility of using alternative separators in macros
@ 2021-05-01 21:50 8% ` Juan Manuel Macías
2021-05-02 21:08 5% ` Christian Moe
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-01 21:50 UTC (permalink / raw)
To: Nicolas Goaziou, Bastien; +Cc: orgmode
Hi all,
Thanks for your comments, Bastien and Nicolas.
I think macros can work out of the box as a perfect 'backend' for those
LaTeX commands that include at least one argument with textual content.
In my case they are very useful to 'extend' the markup language. Apart
from the LaTeX example that I put previously
(\foreignlanguage{lang}{short-text}), there are commands like
\textsc{text in small caps}, \textcolor{color}{text}, and so on. When
one of the arguments consists of textual content, even if it is a short
text, it can be tedious to escape constantly commas[1]. Anyway, I
understand that my use case may not be that of the rest of the users,
and what is a 'problem' for me, it may not be seen as a problem by other
users; therefore, I fully understand Bastien's warnings about making a
modification to something that already works fine, and has been working
fine since always.
Nicolas's suggestion seemed the most reasonable, or the least
destructive, in the hypothetical scenario that there would be a great
demand among users of an alternative separator. Now I see unlikely,
however, that such a demand exists ;-) So, if my use case is a minority,
of course I agree with give up this proposal...
[1] To mitigate 'comma issue' I wrote a function that escapes commas
when saving document :-D
Best regards,
Juan Manuel
Nicolas Goaziou writes:
> Hello,
>
> Bastien <bzg@gnu.org> writes:
>
>> thank you for the patch. I understand the general idea, but I think
>> we should be careful not to overload the macro syntax - escaping the
>> coma seems okay to me. I'm closing this suggestion.
>>
>> I'm cc'ing Nicolas: if he thinks it's a useful addition, I won't of
>> course insist on rejecting it.
>
> This is a followup to a previous discussion in this mailing list, in
> which Juan Manuel explained his use-case for a different argument
> separator in macros. I noticed then that there was an opening for
> a backward compatible syntax extension for it. As I was also not certain
> it would be a good idea overall, I suggested him to start a new, more
> visible, thread with the proposal, and collect feedback.
>
> So, maybe it is a bit early to close it.
>
> BTW, I would like to amend the proposed syntax, so as to limit friction
> with the rest of Org. What would be more reasonable is the following:
>
> {{{macroname·(...)}}}
>
> where · is either nothing or a _single_ printable non-alphanumeric
> non-space non-parenthesis character that isn't already meaningful in
> Org. For example, if for some reason, we limit ourselves to ASCII
> characters only, the set of allowed separators would be:
>
> ! % & , ; ? `
>
> So, again, I'm not saying we should do this. TBH, I'm not convinced by
> the idea of duplicate syntax (comma-escaping and alternate characters)
> for the same thing. But hard-core macro users may have a word to say
> about it.
>
> WDYT?
>
> Regards,
^ permalink raw reply [relevance 8%]
* 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%]
* About multilingual documents
@ 2021-05-02 20:20 8% Juan Manuel Macías
2021-05-03 6:58 5% ` Aleksandar Dimitrov
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-02 20:20 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]
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
[-- Attachment #2: test-langs.org --]
[-- Type: application/vnd.lotus-organizer, Size: 2263 bytes --]
^ permalink raw reply [relevance 8%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-01 21:50 8% ` Juan Manuel Macías
@ 2021-05-02 21:08 5% ` Christian Moe
0 siblings, 0 replies; 200+ results
From: Christian Moe @ 2021-05-02 21:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Bastien, orgmode, Nicolas Goaziou
I frequently need to escape commas in macros, which is a bit of a pain
and easy to forget. My most frequent use case is a macro that expands in
ODT export to a margin comment (like #+begin_annotation does, but
without causing a line break). It takes one argument which typically
consists of several lines of text with commas in them. If I forget to
escape a comma, the rest of the comment is silently lost to the reader.
So a backwards-compatible remedy would be nice. Juan's/Nicholas's
solution is smart, but I'm not sure if it's exactly what I've been
waiting for. It saves escaping every comma, but I'd still have to
remember to add the separator character every time I *invoke* a macro,
and remembering is the tricky part. I don't know if you've already
considered the option of instead specifying a different separator in the
macro *definition*, say something like
#+macro: comment @@html:<!-- $1 -->@@ :sep "&"
Another point: Something that would help, without adding new syntax, is
making macro expansion smart enough to *ignore* separators when the
macro definition contains only *one* argument anyway, as in the cases
above. That behavior would also be safely backwards-compatible, I
think. It would not help with macros with more than one arg, like Juan's
example, but it would solve most of my problems, for example.
Yours,
Christian
Juan Manuel Macías writes:
> Hi all,
>
> Thanks for your comments, Bastien and Nicolas.
>
> I think macros can work out of the box as a perfect 'backend' for those
> LaTeX commands that include at least one argument with textual content.
> In my case they are very useful to 'extend' the markup language. Apart
> from the LaTeX example that I put previously
> (\foreignlanguage{lang}{short-text}), there are commands like
> \textsc{text in small caps}, \textcolor{color}{text}, and so on. When
> one of the arguments consists of textual content, even if it is a short
> text, it can be tedious to escape constantly commas[1]. Anyway, I
> understand that my use case may not be that of the rest of the users,
> and what is a 'problem' for me, it may not be seen as a problem by other
> users; therefore, I fully understand Bastien's warnings about making a
> modification to something that already works fine, and has been working
> fine since always.
>
> Nicolas's suggestion seemed the most reasonable, or the least
> destructive, in the hypothetical scenario that there would be a great
> demand among users of an alternative separator. Now I see unlikely,
> however, that such a demand exists ;-) So, if my use case is a minority,
> of course I agree with give up this proposal...
>
> [1] To mitigate 'comma issue' I wrote a function that escapes commas
> when saving document :-D
>
> Best regards,
>
> Juan Manuel
>
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Bastien <bzg@gnu.org> writes:
>>
>>> thank you for the patch. I understand the general idea, but I think
>>> we should be careful not to overload the macro syntax - escaping the
>>> coma seems okay to me. I'm closing this suggestion.
>>>
>>> I'm cc'ing Nicolas: if he thinks it's a useful addition, I won't of
>>> course insist on rejecting it.
>>
>> This is a followup to a previous discussion in this mailing list, in
>> which Juan Manuel explained his use-case for a different argument
>> separator in macros. I noticed then that there was an opening for
>> a backward compatible syntax extension for it. As I was also not certain
>> it would be a good idea overall, I suggested him to start a new, more
>> visible, thread with the proposal, and collect feedback.
>>
>> So, maybe it is a bit early to close it.
>>
>> BTW, I would like to amend the proposed syntax, so as to limit friction
>> with the rest of Org. What would be more reasonable is the following:
>>
>> {{{macroname·(...)}}}
>>
>> where · is either nothing or a _single_ printable non-alphanumeric
>> non-space non-parenthesis character that isn't already meaningful in
>> Org. For example, if for some reason, we limit ourselves to ASCII
>> characters only, the set of allowed separators would be:
>>
>> ! % & , ; ? `
>>
>> So, again, I'm not saying we should do this. TBH, I'm not convinced by
>> the idea of duplicate syntax (comma-escaping and alternate characters)
>> for the same thing. But hard-core macro users may have a word to say
>> about it.
>>
>> WDYT?
>>
>> Regards,
^ permalink raw reply [relevance 5%]
* Re: About multilingual documents
2021-05-02 20:20 8% About multilingual documents Juan Manuel Macías
@ 2021-05-03 6:58 5% ` Aleksandar Dimitrov
2021-05-03 20:33 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Aleksandar Dimitrov @ 2021-05-03 6:58 UTC (permalink / raw)
To: emacs-orgmode
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 5%]
* Re: About multilingual documents
2021-05-03 6:58 5% ` Aleksandar Dimitrov
@ 2021-05-03 20:33 9% ` Juan Manuel Macías
2021-05-04 8:44 2% ` Aleksandar Dimitrov
0 siblings, 1 reply; 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: About multilingual documents
2021-05-03 20:33 9% ` Juan Manuel Macías
@ 2021-05-04 8:44 2% ` Aleksandar Dimitrov
2021-05-06 11:11 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Aleksandar Dimitrov @ 2021-05-04 8:44 UTC (permalink / raw)
To: org-mode-email
Hi Juan,
> 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)...)'.
What I like about =org-edit-special= is that it gives you a dedicated
little environment in a different language (either natural, or
programming language!) This allows me to focus on the task of editing it
really easily.
I must admit that I find the inline org-src notation (of which I didn't
know yet) somewhat jarring, and certainly less pleasant to read. Perhaps
we could use a similar mechanism to =org-hide-emphasis-markers= to make
it more pleasant to read. [1]
> 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.
I definitely agree that Org would benefit from more multilingual
support. I'm not very experienced in emacs-lisp but would love to contribute.
One problem I foresee is the translation of locales into LaTeX macros
for either (LaTeX)-Babel or Polyglossia (which is what I use.) So a
string like "en" or "en_UK" (which is readily understood by
([ai]|hun)spell) would have to be translated to the necessary
macros. For example for Polyglossia [2] the preamble would read
\setdefaultlanguage[variant=uk]{english}
And then the inline commands would have to be rendered as
\textenglish{…} or \textlang{english}{…} (probably the latter would be easier.)
I forgot what it is for LaTeX-Babel.
Note that the HTML export backend, too, could (or should) support
declaring multiple languages. [3]
There's a lot of work in there, but I would say that any implementation
effort should focus on one thing first. That could be switching the
dictionary on org-edit-special if a :lang-variable is set, or it could
be re-using what you, Juan, already wrote for LaTeX-Babel
exports. Support for Polyglossia or HTML could come at a later time.
Cheers,
Aleks
[1] https://stackoverflow.com/questions/20309842/how-to-syntax-highlight-for-org-mode-inline-source-code-src-lang/28059832#28059832
[2] https://ftp.rrze.uni-erlangen.de/ctan/macros/unicodetex/latex/polyglossia/polyglossia.pdf
[3] https://www.w3.org/International/questions/qa-html-language-declarations
>
> 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 2%]
* Re: About multilingual documents
2021-05-04 8:44 2% ` Aleksandar Dimitrov
@ 2021-05-06 11:11 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-06 11:11 UTC (permalink / raw)
To: Aleksandar Dimitrov; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 4300 bytes --]
Hi Aleksandar,
Aleksandar Dimitrov writes:
> [...]
> I must admit that I find the inline org-src notation (of which I
> didn't know yet) somewhat jarring, and certainly less pleasant to
> read. Perhaps we could use a similar mechanism to
> =org-hide-emphasis-markers= to make it more pleasant to read. [1]
You may be interested in this thread: https://orgmode.org/list/87a6r6avgg.fsf@gmail.com/
> I definitely agree that Org would benefit from more multilingual
> support. I'm not very experienced in emacs-lisp but would love to contribute.
>
> One problem I foresee is the translation of locales into LaTeX macros
> for either (LaTeX)-Babel or Polyglossia (which is what I use.) So a
> string like "en" or "en_UK" (which is readily understood by
> ([ai]|hun)spell) would have to be translated to the necessary
> macros. For example for Polyglossia [2] the preamble would read
>
> \setdefaultlanguage[variant=uk]{english}
>
> And then the inline commands would have to be rendered as
> \textenglish{…} or \textlang{english}{…} (probably the latter would be easier.)
Since these days I had some free time, I have written this little
snippet, based on your idea. Of course, it is only a 'sketch', or a
'proof of concept'. It has obvious limitations and does not collect all
the features that your idea suggests. Here I only apply the (LaTeX)
Babel environments, but they can be easily substituted by those of
Polyglossia [1], or add both possibilities using a defcustom. I have put
two options: `:lang' and `:lang-quotes'. The second option is to use it
with the csquotes package. As I have only focused on exporting to LaTeX
I have not included support for html (or odt), but I agree with you that
it would be necessary to add some multilingual support as well for these
backends. And there's no support for inline blocks either, as the output
of the variables I've added is multiline. Anyway, it is a very hasty
sketch (maybe too hasty ;-)), but if you want to try it, I attach here a
small test document.
The code:
#+begin_src emacs-lisp
(defun my-lang-org-backend (lang body)
(cond
((org-export-derived-backend-p org-export-current-backend 'latex)
(format "@@latex:\\begin{otherlanguage}{%s}@@\n%s\n@@latex:\\end{otherlanguage}@@" lang body))
((or (org-export-derived-backend-p org-export-current-backend 'html)
(org-export-derived-backend-p org-export-current-backend 'odt))
(format "%s" body))))
(defun my-lang-csquotes-org-backend (lang body)
(cond
((org-export-derived-backend-p org-export-current-backend 'latex)
(format "@@latex:\\begin{otherlanguage*}{%s}\n\\EnableQuotes@@\n%s\n@@latex:\\end{otherlanguage*}@@" lang body))
((or (org-export-derived-backend-p org-export-current-backend 'html)
(org-export-derived-backend-p org-export-current-backend 'odt))
(format "%s" body))))
(defun org-babel-execute:org (body params)
"Execute a block of Org code with.
This function is called by `org-babel-execute-src-block'."
(let ((result-params (split-string (or (cdr (assq :results params)) "")))
(lang (cdr (assq :lang params)))
(lang-quotes (cdr (assq :lang-quotes params)))
(body (org-babel-expand-body:org
(replace-regexp-in-string "^," "" body) params)))
(cond
(lang
(my-lang-org-backend lang body))
(lang-quotes
(my-lang-csquotes-org-backend lang-quotes body))
((member "latex" result-params)
(org-export-string-as (concat "#+Title: \n" body) 'latex t))
((member "html" result-params) (org-export-string-as body 'html t))
((member "ascii" result-params) (org-export-string-as body 'ascii t))
(t body))))
#+end_src
Best regards,
Juan Manuel
[1] I used Polyglossia for a while, when I migrated to XeTeX and then to
LuaTeX, and babel at that time did not support both engines. But now
Babel does give them full support and has grown so much that it has
surpassed (IMHO) to Polyglossia. I recommend taking a look at all
novelties and new functionalities that has added the current Babel
maintainer, Javier Bezos:
http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf
[-- Attachment #2: langs-test.org --]
[-- Type: application/vnd.lotus-organizer, Size: 2120 bytes --]
^ permalink raw reply [relevance 6%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-05-01 10:58 6% ` Bastien
2021-05-01 11:46 10% ` Juan Manuel Macías
[not found] ` <87tunlxws3.fsf@ucl.ac.uk>
@ 2021-05-08 7:31 6% ` Juan Manuel Macías
2021-05-15 13:46 6% ` Bastien
2 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-08 7:31 UTC (permalink / raw)
To: orgmode; +Cc: Bastien, TEC, Eric Fraga
[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]
Hi all,
Here I am attaching a new version of the patch that includes a commit
message.
I put here an example for those who want to try it, a fragment of a
poem by W.H. Auden.
Best regards,
Juan Manuel
#+begin_src org
,#+LaTeX_Header: \usepackage{verse}
,#+ATTR_LATEX: :center t
,#+ATTR_LATEX: :versewidth Teach the free man how to praise.
,#+ATTR_LATEX: :lines 5 :latexcode \small
,#+begin_verse
Earth, receive an honoured guest:
William Yeats is laid to rest.
Let the Irish vessel lie
Emptied of its poetry.
In the nightmare of the dark
All the dogs of Europe bark,
And the living nations wait,
Each sequestered in its hate;
Intellectual disgrace
Stares from every human face,
And the seas of pity lie
Locked and frozen in each eye.
Follow, poet, follow right
To the bottom of the night,
With your unconstraining voice
Still persuade us to rejoice;
With the farming of a verse
Make a vineyard of the curse,
Sing of human unsuccess
In a rapture of distress;
In the deserts of the heart
Let the healing fountain start,
In the prison of his days
Teach the free man how to praise.
,#+end_verse
#+end_src
https://juanmanuelmacias.com/
[-- Attachment #2: 0001-Add-LaTeX-attributes-for-verse-blocks.patch --]
[-- Type: text/x-patch, Size: 4774 bytes --]
From 337014731e89f7f28873b8f5d9a917901e810c95 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 8 May 2021 09:03:10 +0200
Subject: [PATCH] Add LaTeX attributes for verse blocks
---
doc/org-manual.org | 48 ++++++++++++++++++++++++++++++++++++++++++++++
lisp/ox-latex.el | 20 +++++++++++++++----
2 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index ab12fa70a..c752ce46d 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13861,6 +13861,54 @@ The LaTeX export back-end converts horizontal rules by the specified
-----
#+end_example
+*** Verse blocks in LaTeX export
+:PROPERTIES:
+:DESCRIPTION: Attributes specific to special blocks.
+:END:
+
+#+cindex: verse blocks, in @LaTeX{} export
+#+cindex: @samp{ATTR_LATEX}, keyword
+
+The LaTeX export back-end accepts four attributes for verse blocks:
+=:lines=, =:center=, =:versewidth= and =:latexcode=. The three first
+require the external LaTeX package =verse.sty=, wich is an extension
+of the standard LaTeX environment. The purpose of these attributes is
+explained below.
+
+- =:lines= :: To add marginal verse numbering. Its value is an
+ integer, the sequence in which the verses should be numbered.
+- =:center= :: With value =t= all the verses on the page are optically
+ centered (a typographic convention for poetry), taking as a
+ reference the longest verse, which must be indicated by the
+ attribute =:versewidth=.
+- =:versewidth= :: Its value is a literal text string with the longest
+ verse.
+- =:latexcode= :: It accepts any arbitrary LaTeX code that can be
+ included within a LaTeX =verse= environment.
+
+A complete example with Shakespeare's first sonnet:
+
+#+begin_src org
+,#+ATTR_LaTeX: :center t :latexcode \color{red} :lines 5
+,#+ATTR_LaTeX: :versewidth Feed’st thy light’st flame with self-substantial fuel,
+,#+begin_verse
+From fairest creatures we desire increase,
+That thereby beauty’s rose might never die,
+But as the riper should by time decrease,
+His tender heir mught bear his memeory:
+But thou, contracted to thine own bright eyes,
+Feed’st thy light’st flame with self-substantial fuel,
+Making a famine where abundance lies,
+Thyself thy foe, to thy sweet self too cruel.
+Thou that art now the world’s fresh ornament
+And only herald to the gaudy spring,
+Within thine own bud buriest thy content
+And, tender churl, makest waste in niggarding.
+Pity the world, or else this glutton be,
+To eat the world’s due, by the grave and thee.
+,#+end_verse
+#+end_src
+
** Markdown Export
:PROPERTIES:
:DESCRIPTION: Exporting to Markdown.
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index c3fc83b1b..0376dffd1 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3513,6 +3513,17 @@ channel."
"Transcode a VERSE-BLOCK element from Org to LaTeX.
CONTENTS is verse block contents. INFO is a plist holding
contextual information."
+ (let*
+ ((lin (org-export-read-attribute :attr_latex verse-block :lines))
+ (latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
+ (cent (org-export-read-attribute :attr_latex verse-block :center))
+ (attr (concat
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if latcode (format "\n%s" latcode) "")))
+ (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
+ (vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
+ (linreset (if lin "\n\\poemlines{0}" "")))
(concat
(org-latex--wrap-label
verse-block
@@ -3520,19 +3531,20 @@ contextual information."
;; character and change each white space at beginning of a line
;; into a space of 1 em. Also change each blank line with
;; a vertical space of 1 em.
- (format "\\begin{verse}\n%s\\end{verse}"
+ (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
"^[ \t]*\\\\\\\\$" "\\vspace*{1em}"
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n" "\\\\\n"
- contents nil t) nil t) nil t))
+ contents nil t) nil t) nil t) linreset)
info)
;; Insert footnote definitions, if any, after the environment, so
;; the special formatting above is not applied to them.
- (org-latex--delayed-footnotes-definitions verse-block info)))
-
+ (org-latex--delayed-footnotes-definitions verse-block info))))
\f
;;; End-user functions
--
2.26.0
^ permalink raw reply related [relevance 6%]
* [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: [PATCH] Possibility of using alternative separators in macros
2021-04-30 13:26 6% [PATCH] Possibility of using alternative separators in macros Juan Manuel Macías
@ 2021-05-11 11:01 5% ` Eric S Fraga
2021-05-11 16:12 5% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Eric S Fraga @ 2021-05-11 11:01 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello Juan,
On Friday, 30 Apr 2021 at 13:26, Juan Manuel Macías wrote:
> Hi all,
>
> I would like to propose (patch attached) the possibility of using an
> alternate character for separate arguments in replacement macros,
> following a suggestion from Nicolas Goaziou in this (closed) thread:
> https://orgmode.org/list/87o8ead42u.fsf@nicolasgoaziou.fr/
I finally got around to trying this out, applying the patch just now to
the latest org from the git repository. I get the following when I try
to export:
Debugger entered--Lisp error: (void-variable sep)
org-element-macro-parser()
org-element--object-lex((bold code entity export-snippet footnote-reference inline-babel-call inline-src-block italic line-break latex-fragment link macro radio-target statistics-cookie strike-through subscript superscript target timestamp underline verbatim))
org-element-context()
org-macro-replace-all((("date" . "") ("title" . "The title") ("email" . "") ("author" . "Professor Eric S Fraga") ("lastchange" . "2021.03.31 15:03") ("calc" . "@@latex:{\\color{green!50!black}\\texttt{ $1 }}@@") ("cite" . "[[$2][@@latex:\\vfill\\Citation{$1}@@]]") ("overlay" . "@@latex:\\begin{textblock}{$4}($2,$3)@@[[file:$1]]@...") ("parameter" . "src_elisp[:results value raw :var $1=(esf/get-para...") ("constant" closure (t) (&optional $1 &rest _) (progn (message "Getting constant %s" $1) (org-table-get-constant $1))) ("input-file" . "m.org") ("modification-time" . #f(compiled-function (arg1 &optional arg2 &rest _) #<bytecode 0x1a91bc3b547f3a1c>)) ("keyword" lambda (arg1 &rest _) (org-macro--find-keyword-value arg1)) ("n" lambda (&optional arg1 arg2 &rest _) (org-macro--counter-increment arg1 arg2)) ("property" lambda (arg1 &optional arg2 &rest _) (org-macro--get-property arg1 arg2)) ("time" lambda (arg1 &rest _) (format-time-string arg1))) ("DESCRIPTION" "KEYWORDS" "SUBTITLE" "DATE" "TITLE" "DATE" "AUTHOR"))
org-export-as(latex nil nil nil nil)
org-export-to-buffer(latex "*Org LATEX Export*" nil nil nil nil nil #f(compiled-function () #<bytecode 0xbb0539acd91d>))
org-latex-export-as-latex(nil nil nil nil)
org-export-dispatch(nil)
funcall-interactively(org-export-dispatch nil)
command-execute(org-export-dispatch)
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-534-g8f03cd.dirty
^ permalink raw reply [relevance 5%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-11 11:01 5% ` Eric S Fraga
@ 2021-05-11 16:12 5% ` Juan Manuel Macías
[not found] ` <87im3prvz8.fsf@ucl.ac.uk>
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-11 16:12 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Hello Eric,
It's a typo, sorry: I forgot, when I made the patch, to add the asterisk
to the `let' expression in org-element-macro-parser, therefore the `sep'
variable was not recognized.
The correct function is:
(defun org-element-macro-parser ()
"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', `:sep' 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_]*\\)\\([^a-zA-Z\s()]?[^-a-zA-Z0-9_\s]?\\)\\((\\([^\000]*?\\))\\)?}}}")
(let* ((begin (point)) ;; <==== missing asterisk :-(
(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 4)
(`nil nil)
(a (org-macro-extract-arguments
sep
(replace-regexp-in-string
"[ \t\r\n]+" " " (org-trim a)))))))
(list 'macro
(list :key key
:value value
:args args
:begin begin
:end end
:sep sep
:post-blank post-blank))))))
Eric S Fraga writes:
> Hello Juan,
>
> On Friday, 30 Apr 2021 at 13:26, Juan Manuel Macías wrote:
>> Hi all,
>>
>> I would like to propose (patch attached) the possibility of using an
>> alternate character for separate arguments in replacement macros,
>> following a suggestion from Nicolas Goaziou in this (closed) thread:
>> https://orgmode.org/list/87o8ead42u.fsf@nicolasgoaziou.fr/
>
> I finally got around to trying this out, applying the patch just now to
> the latest org from the git repository. I get the following when I try
> to export:
>
> Debugger entered--Lisp error: (void-variable sep)
> org-element-macro-parser()
> org-element--object-lex((bold code entity export-snippet
> footnote-reference inline-babel-call inline-src-block italic
> line-break latex-fragment link macro radio-target statistics-cookie
> strike-through subscript superscript target timestamp underline
> verbatim))
> org-element-context()
> org-macro-replace-all((("date" . "") ("title" . "The title")
> ("email" . "") ("author" . "Professor Eric S Fraga") ("lastchange" .
> "2021.03.31 15:03") ("calc" .
> "@@latex:{\\color{green!50!black}\\texttt{ $1 }}@@") ("cite" .
> "[[$2][@@latex:\\vfill\\Citation{$1}@@]]") ("overlay" .
> "@@latex:\\begin{textblock}{$4}($2,$3)@@[[file:$1]]@...") ("parameter"
> . "src_elisp[:results value raw :var $1=(esf/get-para...") ("constant"
> closure (t) (&optional $1 &rest _) (progn (message "Getting constant
> %s" $1) (org-table-get-constant $1))) ("input-file" . "m.org")
> ("modification-time" . #f(compiled-function (arg1 &optional arg2 &rest
> _) #<bytecode 0x1a91bc3b547f3a1c>)) ("keyword" lambda (arg1 &rest _)
> (org-macro--find-keyword-value arg1)) ("n" lambda (&optional arg1 arg2
> &rest _) (org-macro--counter-increment arg1 arg2)) ("property" lambda
> (arg1 &optional arg2 &rest _) (org-macro--get-property arg1 arg2))
> ("time" lambda (arg1 &rest _) (format-time-string arg1)))
> ("DESCRIPTION" "KEYWORDS" "SUBTITLE" "DATE" "TITLE" "DATE" "AUTHOR"))
> org-export-as(latex nil nil nil nil)
> org-export-to-buffer(latex "*Org LATEX Export*" nil nil nil nil nil #f(compiled-function () #<bytecode 0xbb0539acd91d>))
> org-latex-export-as-latex(nil nil nil nil)
> org-export-dispatch(nil)
> funcall-interactively(org-export-dispatch nil)
> command-execute(org-export-dispatch)
^ permalink raw reply [relevance 5%]
* 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
2021-05-15 13:29 6% ` Bastien
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: [PATCH] Possibility of using alternative separators in macros
2021-05-11 18:25 9% ` Juan Manuel Macías
@ 2021-05-15 13:29 6% ` Bastien
2021-05-15 20:14 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Bastien @ 2021-05-15 13:29 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Eric S Fraga
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Here is the fixed version of the patch.
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.
Thanks,
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-05-08 7:31 6% ` Juan Manuel Macías
@ 2021-05-15 13:46 6% ` Bastien
0 siblings, 0 replies; 200+ results
From: Bastien @ 2021-05-15 13:46 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Eric Fraga, orgmode, TEC
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Here I am attaching a new version of the patch that includes a commit
> message.
Correct me if I'm wrong but the patch did not contain a commit
message, so I added it.
Applied in master, together with an entry in etc/ORG-NEWS.
Thanks,
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [patch] to allow org-attach-git to handle individual repositories
2021-04-28 3:57 6% ` Bastien
@ 2021-05-15 14:08 6% ` Bastien
1 sibling, 0 replies; 200+ results
From: Bastien @ 2021-05-15 14:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Ihor Radchenko
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I would like to propose and discuss this patch for org-attach-git,
> following a series of comments and suggestions from Ihor Radchenko in
> this thread:
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00483.html
Applied in master with a commit message, thanks.
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-15 13:29 6% ` Bastien
@ 2021-05-15 20:14 9% ` Juan Manuel Macías
2021-05-15 20:25 6% ` Bastien
0 siblings, 1 reply; 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: [PATCH] Possibility of using alternative separators in macros
2021-05-15 20:14 9% ` Juan Manuel Macías
@ 2021-05-15 20:25 6% ` Bastien
2021-05-15 21:05 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Bastien @ 2021-05-15 20:25 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Eric S Fraga
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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?
I'm skeptical too, so perhaps the best thing to do is to see if you
need it or not, and if proven useful after a while, repost a patch?
Thanks!
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-15 20:25 6% ` Bastien
@ 2021-05-15 21:05 10% ` Juan Manuel Macías
2021-05-16 12:17 6% ` Bastien
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-15 21:05 UTC (permalink / raw)
To: Bastien; +Cc: orgmode, Eric S Fraga
Hi Bastien,
Bastien writes:
> I'm skeptical too, so perhaps the best thing to do is to see if you
> need it or not, and if proven useful after a while, repost a patch?
I totally agree. I will try these modifications for a while, if they are
really useful. Anyway, as Nicolas commented in a previous post, it seems
that the natural habitat of macros consists of short lengths of text. I
am exploring now other interesting alternatives (ie.
org-link-set-parameters).
(On the other hand, maybe better than an alternate separator, some kind of
warning for unescaped commas might be more useful, as Maxim commented
here: https://orgmode.org/list/s7gfc6@ciao.gmane.io/)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-15 21:05 10% ` Juan Manuel Macías
@ 2021-05-16 12:17 6% ` Bastien
2021-05-16 16:48 0% ` Maxim Nikulin
0 siblings, 1 reply; 200+ results
From: Bastien @ 2021-05-16 12:17 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Eric S Fraga
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> (On the other hand, maybe better than an alternate separator, some kind of
> warning for unescaped commas might be more useful, as Maxim commented
> here: https://orgmode.org/list/s7gfc6@ciao.gmane.io/)
Yes, probably -- feel free to propose a patch for this. Thanks!
--
Bastien
^ permalink raw reply [relevance 6%]
* [Question] Custom parse tree filter
@ 2021-05-16 15:31 8% Juan Manuel Macías
2021-05-16 15:59 5% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-16 15:31 UTC (permalink / raw)
To: orgmode
Hi all,
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!
Best regards,
Juan Manuel
#+BIND: org-export-filter-parse-tree-functions (my-custom-filters/fontspec-headline)
#+begin_src emacs-lisp :exports results :results none
(defun my-custom-filters/fontspec-headline (tree backend info)
(when (org-export-derived-backend-p backend 'latex)
(org-element-map tree 'headline
(lambda (hl)
(cond ((org-element-property :FONT hl)
(let* ((font (org-element-property :FONT hl))
(contents (org-element-interpret-data (org-element-contents hl)))
(contents-new (concat
"@@latex:{\\fontspec{@@"
(replace-regexp-in-string "\s*\\(\\[.+\\]\\)\s*" "" font)
"@@latex:}%@@\n"
(if (string-match "\\(\\[.+\\]\\)" font)
(concat "@@latex:" (match-string 1 font) "%@@\n\n")
"\n")
contents
"\n@@latex:}@@")))
(org-element-set-contents hl (with-temp-buffer
(insert contents-new)
(org-element-parse-buffer)))))
((org-element-property :FONTFEATURE hl)
(let* ((fontfeature (org-element-property :FONTFEATURE hl))
(contents (org-element-interpret-data (org-element-contents hl)))
(contents-new (concat
"@@latex:{\\addfontfeature{@@"
fontfeature
"@@latex:}%@@\n"
contents
"\n@@latex:}@@")))
(org-element-set-contents hl (with-temp-buffer
(insert contents-new)
(org-element-parse-buffer)))))))
info)
tree))
#+end_src
* Minion Pro
:PROPERTIES:
:font: Minion Pro [Style=Historic,Color=teal]
:END:
Lorem ipsum dolor.
** Lowercase Numbers
:PROPERTIES:
:fontfeature: Numbers=Lowercase
:END:
Lorem ipsum dolor 1234567890.
*** Letter Space
:PROPERTIES:
:fontfeature: LetterSpace=14.6
:END:
Lorem ipsum dolor 1234567890.
^ permalink raw reply [relevance 8%]
* Re: [Question] Custom parse tree filter
2021-05-16 15:31 8% [Question] Custom parse tree filter Juan Manuel Macías
@ 2021-05-16 15:59 5% ` Nicolas Goaziou
2021-05-17 12:20 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-05-16 15:59 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
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.
--8<---------------cut here---------------start------------->8---
(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))
--8<---------------cut here---------------end--------------->8---
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,
--
Nicolas Goaziou
^ permalink raw reply [relevance 5%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-16 12:17 6% ` Bastien
@ 2021-05-16 16:48 0% ` Maxim Nikulin
0 siblings, 0 replies; 200+ results
From: Maxim Nikulin @ 2021-05-16 16:48 UTC (permalink / raw)
To: emacs-orgmode
On 16/05/2021 19:17, Bastien wrote:
>
> Juan Manuel Macías writes:
>
>> (On the other hand, maybe better than an alternate separator, some kind of
>> warning for unescaped commas might be more useful, as Maxim commented
>> here: https://orgmode.org/list/s7gfc6@ciao.gmane.io/)
>
> Yes, probably -- feel free to propose a patch for this. Thanks!
Such warnings should be property of particular macros. Sometimes
ignoring of arguments may be handy. So no patch is required. The trick
could be documented somewhere, but I am unsure concerning proper place.
Actually, I do not think, fatal error is user-friendly behavior. I am
not aware if export already have convenient facilities to report
warnings. Currently I do not feel I am ready to implement such feature
if it does not exist yet.
However the point of that message was that extra commas may be made
"transparent" for macros by introducing additional substitution, e.g.
"$_" that expands into "rest" arguments. I consider "$@" or "$*" as
worse variant since it rather mean "all arguments", so it is less
flexible. For "eval" lisp macros, it is just replacing "_" by "$_" in
argument list. Simple text macros require a bit more work but it is
still comparable with documenting the feature.
We need a decision if "rest arguments" feature should be introduced.
Once added, it will be harder to discard it due to compatibility issues.
^ permalink raw reply [relevance 0%]
* Re: [Question] Custom parse tree filter
2021-05-16 15:59 5% ` Nicolas Goaziou
@ 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%]
* Multilingual support (proposals and state of the question)
@ 2021-05-17 15:41 8% Juan Manuel Macías
2021-05-17 16:03 6% ` Denis Maier
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-17 15:41 UTC (permalink / raw)
To: orgmode
Hi all,
I would like to start a thread on this question, leaving some basic ideas and
sketches of my own, in case someone else wanted to join the discussion.
I think it would be nice if Org Mode offered consistent support (out of
the box) for multilingual documents. That is, those documents where
there is a main language and it is possible to toggle between a list of
others 'secondary' languages, in the LaTeX Babel way. Those documents
could be consistently exported to other formats with multilingual
support: LaTeX, of course, but also html, odt, etc.
What is your opinion?
I think Org documents should have three levels in multilingual management:
- Short text segments, something like an 'inline block' for other languages
- Blocks
- Sections
For short inline segments, IMHO and without the need to innovate, I
think an excellent candidate are the links defined with
org-link-set-parameters. For example:
Lorem ipsum [[lang:de][some text in German]] dolor sit amet
(For structures of this kind I found very interesting ideas here:
https://github.com/alhassy/org-special-block-extras)
As for blocks, I think of a hypothetical 'lang' block:
#+begin_lang el :variant polytonic
Some text in polytonic Greek...
#+end_lang
However, in a previous thread
(https://orgmode.org/list/87k0og8fss.fsf@list.aleks.bg/) Aleksandar
Dimitrov proposed an idea that seemed very suggestive, at least in
concept: add a ':lang' argument to the Org code blocks:
#+begin_src org :lang fr
Some text in french
#+end_src
And finally, for sections, you could think of a new property ':lang:'
* Header
:PROPERTIES:
:LANG: pt
:END:
...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Multilingual support (proposals and state of the question)
2021-05-17 15:41 8% Multilingual support (proposals and state of the question) Juan Manuel Macías
@ 2021-05-17 16:03 6% ` Denis Maier
2021-05-17 18:10 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Denis Maier @ 2021-05-17 16:03 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
Am 17.05.2021 um 17:41 schrieb Juan Manuel Macías:
> Hi all,
>
> I would like to start a thread on this question, leaving some basic ideas and
> sketches of my own, in case someone else wanted to join the discussion.
>
> I think it would be nice if Org Mode offered consistent support (out of
> the box) for multilingual documents. That is, those documents where
> there is a main language and it is possible to toggle between a list of
> others 'secondary' languages, in the LaTeX Babel way. Those documents
> could be consistently exported to other formats with multilingual
> support: LaTeX, of course, but also html, odt, etc.
>
> What is your opinion?
>
> I think Org documents should have three levels in multilingual management:
>
> - Short text segments, something like an 'inline block' for other languages
> - Blocks
> - Sections
>
> For short inline segments, IMHO and without the need to innovate, I
> think an excellent candidate are the links defined with
> org-link-set-parameters. For example:
>
> Lorem ipsum [[lang:de][some text in German]] dolor sit amet
>
> (For structures of this kind I found very interesting ideas here:
> https://github.com/alhassy/org-special-block-extras)
>
> As for blocks, I think of a hypothetical 'lang' block:
>
> #+begin_lang el :variant polytonic
> Some text in polytonic Greek...
> #+end_lang
>
> However, in a previous thread
> (https://orgmode.org/list/87k0og8fss.fsf@list.aleks.bg/) Aleksandar
> Dimitrov proposed an idea that seemed very suggestive, at least in
> concept: add a ':lang' argument to the Org code blocks:
>
> #+begin_src org :lang fr
> Some text in french
> #+end_src
Why not add a :lang property to other blocks as well?
#+begin_quote :lang en
this is english.
#+end_quote
WDYT?
Denis
^ permalink raw reply [relevance 6%]
* Re: Multilingual support (proposals and state of the question)
2021-05-17 16:03 6% ` Denis Maier
@ 2021-05-17 18:10 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-17 18:10 UTC (permalink / raw)
To: Denis Maier; +Cc: orgmode
Hi Denis,
Denis Maier writes:
> Why not add a :lang property to other blocks as well?
>
> #+begin_quote :lang en
> this is english.
> #+end_quote
>
> WDYT?
>
> Denis
It's an interesting possibility. However, I think that the advantage of
Org src blocks is that you can include anything you want, even quote
blocks. And you also have org-edit-special...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [org-footnote--allow-reference-p]
@ 2021-05-20 10:17 10% ` Juan Manuel Macías
2021-05-20 10:21 0% ` [org-footnote--allow-reference-p] Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-20 10:17 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe,
Uwe Brauer writes:
> It seems that the function org-footnote--allow-reference-p
> is the culprit, but which places are *forbidden* the doc string does not
> say much.
If you mean to insert a note in an empty cell, you can insert just
before the note mark a zero width space (M-x insert-char RET 200b RET)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [org-footnote--allow-reference-p]
2021-05-20 10:17 10% ` [org-footnote--allow-reference-p] Juan Manuel Macías
@ 2021-05-20 10:21 0% ` Uwe Brauer
2021-05-20 10:38 10% ` [org-footnote--allow-reference-p] Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2021-05-20 10:21 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 534 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Uwe,
> Uwe Brauer writes:
>> It seems that the function org-footnote--allow-reference-p
>> is the culprit, but which places are *forbidden* the doc string does not
>> say much.
> If you mean to insert a note in an empty cell, you can insert just
> before the note mark a zero width space (M-x insert-char RET 200b RET)
Ah! That was it, thanks!
I think the documentation of org-footnote-action
could be a bit more explicit and cover this case.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [org-footnote--allow-reference-p]
2021-05-20 10:21 0% ` [org-footnote--allow-reference-p] Uwe Brauer
@ 2021-05-20 10:38 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-20 10:38 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Ah! That was it, thanks!
> I think the documentation of org-footnote-action
> could be a bit more explicit and cover this case.
In the manual the use of the zero width space character is in the section
'Escape Character'. Perhaps it would be nice to add more usage examples. A
very typical (and practical) use is when you want to emphasize a part of a
word:
with /meta/<zero-with-space>literature you get (LaTeX)
\emph{meta}literature instead of the literal /meta/literature...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* An attempt to prepare critical editions within Org
@ 2021-05-20 11:45 8% Juan Manuel Macías
2021-05-20 12:24 6% ` Denis Maier
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-20 11:45 UTC (permalink / raw)
To: orgmode
Hi,
If there is a philologist among the colisters who is working on critical
editions (a type of text with several complex apparatus of footnotes and
endnotes, and with numbering and various material at the margin ---an
example of critical edition I recently typesetted for a German publisher:
https://maciaschain.gitlab.io/lunotipia/images/muestras_cariton1.png),
you may find the following interesting.
I am working on a package, org-critical-edition, to prepare philological
critical editions from the comfort of Org Mode. The natural backend of
these documents should be LaTeX with the 'reledmac' package
(https://ctan.org/pkg/reledmac), an excellent package mantained by
Maïeul Rouquette (https://github.com/maieul/ledmac), that is the most
mature option to work in this type of texts within LaTeX. But in the
future I may add some support to export data to the TEI-xml standard,
widely used in Humanities.
The basic idea of my package is that the 'critical notes' are always
hidden and only the annotated passages are shown in the text (they are
actually Org links, but what is shown is the target, while the
description and the target label remains invisible). Each critical note
can be edited or created (over a marked region) in a dedicated buffer.
Soon I will upload to GitLab a first version of the package (quite
immature at the moment: feedback welcome!) but here is a brief
screencast:
https://lunotipia.juanmanuelmacias.com/images/org-critical-edition.mp4
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: An attempt to prepare critical editions within Org
2021-05-20 11:45 8% An attempt to prepare critical editions within Org Juan Manuel Macías
@ 2021-05-20 12:24 6% ` Denis Maier
0 siblings, 0 replies; 200+ results
From: Denis Maier @ 2021-05-20 12:24 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
Am 20.05.2021 um 13:45 schrieb Juan Manuel Macías:
> Hi,
>
> If there is a philologist among the colisters who is working on critical
> editions (a type of text with several complex apparatus of footnotes and
> endnotes, and with numbering and various material at the margin ---an
> example of critical edition I recently typesetted for a German publisher:
> https://maciaschain.gitlab.io/lunotipia/images/muestras_cariton1.png),
> you may find the following interesting.
>
> I am working on a package, org-critical-edition, to prepare philological
> critical editions from the comfort of Org Mode. The natural backend of
> these documents should be LaTeX with the 'reledmac' package
> (https://ctan.org/pkg/reledmac), an excellent package mantained by
> Maïeul Rouquette (https://github.com/maieul/ledmac), that is the most
> mature option to work in this type of texts within LaTeX. But in the
> future I may add some support to export data to the TEI-xml standard,
> widely used in Humanities.
>
> The basic idea of my package is that the 'critical notes' are always
> hidden and only the annotated passages are shown in the text (they are
> actually Org links, but what is shown is the target, while the
> description and the target label remains invisible). Each critical note
> can be edited or created (over a marked region) in a dedicated buffer.
>
> Soon I will upload to GitLab a first version of the package (quite
> immature at the moment: feedback welcome!) but here is a brief
> screencast:
> https://lunotipia.juanmanuelmacias.com/images/org-critical-edition.mp4
>
> Best regards,
>
> Juan Manuel
>
Not a philologist, but that looks very promising.
Denis
^ permalink raw reply [relevance 6%]
* [PATCH] org.el: use only link descriptions in indirect buffer names
@ 2021-05-22 14:12 9% Juan Manuel Macías
2021-05-23 10:41 6% ` Ihor Radchenko
0 siblings, 1 reply; 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%]
* Re: [PATCH] org.el: use only link descriptions in indirect buffer names
2021-05-22 14:12 9% [PATCH] org.el: use only link descriptions in indirect buffer names Juan Manuel Macías
@ 2021-05-23 10:41 6% ` Ihor Radchenko
2021-05-23 11:25 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-05-23 10:41 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> + 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)))
You can simply do (org-link-display-format (org-get-heading 'no-tags))
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: [PATCH] org.el: use only link descriptions in indirect buffer names
2021-05-23 10:41 6% ` Ihor Radchenko
@ 2021-05-23 11:25 9% ` Juan Manuel Macías
2021-09-26 7:40 6% ` Bastien
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-23 11:25 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
Ihor Radchenko writes:
> You can simply do (org-link-display-format (org-get-heading 'no-tags))
>
> Best,
> Ihor
Oh!! I see that with my code I just reinvented the wheel :-D:
---
org-link-display-format is a compiled Lisp function in ‘ol.el’.
(org-link-display-format S)
Replace links in string S with their description.
If there is no description, use the link target.
---
Thank you very much for the suggestion, Ihor!
(new patch attached)
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: 953 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,7 @@ 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 (org-link-display-format (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%]
* [PATCH] ox-latex.el: add LaTeX attributes to quote block
@ 2021-05-24 12:14 7% Juan Manuel Macías
2021-05-25 9:21 5% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-24 12:14 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]
Hi all,
The `quote' block is exported to LaTeX as a `quote' environment.
However, standard LaTeX classes have two environments for quotes:
`quote' and `quotation', with certain format differences: it is often
said that `quotation' is intended for longer quotes with several
paragraphs and applies a first line indent to each paragraph. In
addition there are several very popular packages that offer more
environments and features for quoting, for example `quoting' or
`csquotes', which includes a set of quote environments and very powerful
options. Even some languages as Spanish option for Babel have their own
quoting environment. Given all this variety, I think it would be nice to
offer the user at least a couple of LaTeX attributes to choose:
`:environment' (by default the environment would remain `quote') and
`:options'. I attach a possible patch for it (if the patch sounds good,
I can add the documentation for the new features).
An example with a quote in German:
#+LaTeX_Header:\usepackage[german,english]{babel}
#+LaTeX_Header:\usepackage{quoting}
#+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
#+LaTeX_Header:\SetBlockEnvironment{quoting}
#+ATTR_LaTeX: :environment foreigndisplayquote :options {german}
#+begin_quote
Eine Erklärung, wie sie einer Schrift in einer Vorrede nach der
Gewohnheit vorausgeschickt wird ---über den Zweck, den der Verfasser
sich in ihr vorgesetzt, sowie über die Veranlassungen und das
Verhältnis, worin er sie zu andern frühern oder gleichzeitigen
Behandlungen desselben Gegenstandes zu stehen glaubt--- scheint bei
einer philosophischen Schrift nicht nur überflüssig, sondern um der
Natur der Sache willen sogar unpassend und zweckwidrig zu sein (Hegel).
#+end_quote
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-latex.el-add-LaTeX-attributes-to-quote-block.patch --]
[-- Type: text/x-patch, Size: 2368 bytes --]
From 1164c3066f0ea7e639382b01c5da2d7b5b46efb8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 24 May 2021 13:19:01 +0200
Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
* lisp/ox-latex.el: 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 | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index b9ecf070a..3704267c9 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' environment."
+ :group 'org-export-latex
+ :version "24.4"
+ :package-version '(Org . "8.0")
+ :type 'string)
+
(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 "")))
(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}"
+ current-env
+ current-opt
+ contents
+ current-env)
+ info)))
;;;; Radio Target
--
2.26.0
^ permalink raw reply related [relevance 7%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-24 12:14 7% [PATCH] ox-latex.el: add LaTeX attributes to quote block Juan Manuel Macías
@ 2021-05-25 9:21 5% ` Nicolas Goaziou
2021-05-25 12:42 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-05-25 9:21 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
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,
--
Nicolas Goaziou
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-25 9:21 5% ` Nicolas Goaziou
@ 2021-05-25 12:42 8% ` Juan Manuel Macías
2021-05-25 15:52 6% ` Nicolas Goaziou
0 siblings, 1 reply; 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: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-25 12:42 8% ` Juan Manuel Macías
@ 2021-05-25 15:52 6% ` Nicolas Goaziou
2021-05-25 20:50 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-05-25 15:52 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Thank you for your indications. Attached the updated patch.
Thanks.
I forgot to ask: could you add some documentation about it in the
manual, too?
> Do you need me to prepare another patch to document the modifications
> and add them to org-NEWS?
You can do it in the same patch.
Regards,
^ permalink raw reply [relevance 6%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-25 15:52 6% ` Nicolas Goaziou
@ 2021-05-25 20:50 7% ` Juan Manuel Macías
2021-05-26 21:05 5% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-25 20:50 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 191 bytes --]
Hi Nicolas,
Nicolas Goaziou writes:
> You can do it in the same patch.
Here is the updated patch, with the corresponding additions in the
manual and ORG-NEWS.
Best regards,
Juan Manuel
[-- Attachment #2: 0001-ox-latex.el-add-LaTeX-attributes-to-quote-block.patch --]
[-- Type: text/x-patch, Size: 4973 bytes --]
From 987566d52cd36c990d3db3f83d2c6433254ac2e3 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 25 May 2021 22:18:06 +0200
Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
* doc/org-manual.org (Quote blocks in LaTeX export): manual updated
* etc/ORG-NEWS (Support quote blocks in LaTeX export): news updated
* 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'
---
doc/org-manual.org | 42 ++++++++++++++++++++++++++++++++++++++++++
etc/ORG-NEWS | 7 +++++++
lisp/ox-latex.el | 22 ++++++++++++++++++++--
3 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 118d97e0e..dd51df27e 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13919,6 +13919,48 @@ To eat the world’s due, by the grave and thee.
,#+END_VERSE
#+end_src
+*** Quote blocks in LaTeX export
+:PROPERTIES:
+:DESCRIPTION: Attributes specific to quote blocks.
+:END:
+
+#+cindex: quote blocks, in @LaTeX{} export
+#+cindex: @samp{ATTR_LATEX}, keyword
+#+cindex: org-latex-default-quote-environment
+
+The LaTeX export back-end accepts two attributes for quote blocks:
+=:environment=, for an arbitrary quoting environment (the default
+value is that of =org-latex-default-quote-environment=: ="quote"=) and
+=:options=. For example, to choose the environment =quotation=,
+included as an alternative to =quote= in standard LaTeX classes:
+
+#+begin_example
+,#+ATTR_LATEX: :environment quotation
+,#+BEGIN_QUOTE
+some text...
+,#+END_QUOTE
+#+end_example
+
+To choose the =foreigndisplayquote= environment, included in the LaTeX
+package =csquotes=, with the =german= option, use this syntax:
+
+#+begin_example
+,#+LATEX_HEADER:\usepackage[autostyle=true]{csquotes}
+,#+ATTR_LATEX: :environment foreigndisplayquote :options {german}
+,#+BEGIN_QUOTE
+some text in German...
+,#+END_QUOTE
+#+end_example
+
+#+texinfo: @noindent
+which is exported to LaTeX as
+
+#+begin_example
+\begin{foreigndisplayquote}{german}
+some text in German...
+\end{foreigndisplayquote}
+#+end_example
+
** Markdown Export
:PROPERTIES:
:DESCRIPTION: Exporting to Markdown.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 8707222e0..c8a93c933 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -244,6 +244,13 @@ require the external LaTeX package =verse.sty=, wich is an extension
of the standard LaTeX environment. The purpose of these attributes is
explained below.
+*** Support quote blocks in LaTeX export
+
+The LaTeX export back-end accepts two attributes for quote blocks:
+=:environment=, for an arbitrary quoting environment (the default
+value is that of =org-latex-default-quote-environment=: ="quote"=) and
+=:options=.
+
*** =org-set-tags-command= selects tags from ~org-global-tags-completion-table~
Let ~org-set-tags-command~ TAB fast tag completion interface complete
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index b9ecf070a..9e2e7be47 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 7%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-25 20:50 7% ` Juan Manuel Macías
@ 2021-05-26 21:05 5% ` Nicolas Goaziou
2021-05-26 23:02 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-05-26 21:05 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Here is the updated patch, with the corresponding additions in the
> manual and ORG-NEWS.
Thanks.
I cannot apply it on top of master however. On what commit did you base
it?
There are also some nits, but I can fix them when applying your patch.
> +#+cindex: quote blocks, in @LaTeX{} export
> +#+cindex: @samp{ATTR_LATEX}, keyword
This is not related to your patch (it can be encountered elsewhere), but
the index entry above is too generic to be useful. Maybe
#+cindex: @samp{ATTR_LATEX}, in quote blocks
would be better.
> +#+cindex: org-latex-default-quote-environment
This should be #+vindex: ...
> +The LaTeX export back-end accepts two attributes for quote blocks:
> +=:environment=, for an arbitrary quoting environment (the default
> +value is that of =org-latex-default-quote-environment=: ="quote"=) and
~org-latex-default-quote-environment~ and ~"quote"~ since they both
refer to Lisp code, not Org syntax.
> +=:options=. For example, to choose the environment =quotation=,
> +included as an alternative to =quote= in standard LaTeX classes:
> +
> +#+begin_example
> +,#+ATTR_LATEX: :environment quotation
> +,#+BEGIN_QUOTE
> +some text...
> +,#+END_QUOTE
> +#+end_example
Note that you can currently write, perhaps more elegantly,
#+begin_quotation
some text...
#+end_quotation
> +To choose the =foreigndisplayquote= environment, included in the LaTeX
> +package =csquotes=, with the =german= option, use this syntax:
> +
> +#+begin_example
> +,#+LATEX_HEADER:\usepackage[autostyle=true]{csquotes}
> +,#+ATTR_LATEX: :environment foreigndisplayquote :options {german}
> +,#+BEGIN_QUOTE
> +some text in German...
> +,#+END_QUOTE
> +#+end_example
I don't know if this example is a good illustration because you can
currently achieve the same with:
#+attr_latex: :options {german}
#+begin_foreigndisplayquote
some text in German...
#+end_foreigndisplayquote
Are there use cases that would be better than using special blocks as in
the example above?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-26 21:05 5% ` Nicolas Goaziou
@ 2021-05-26 23:02 6% ` Juan Manuel Macías
2021-05-29 20:22 6% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-26 23:02 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]
Nicolas Goaziou writes:
> I cannot apply it on top of master however. On what commit did you base
> it?
I'm sorry, it's my fault. It's already fixed. I think the patch attached
here should apply well...
> [...]
> I don't know if this example is a good illustration because you can
> currently achieve the same with:
>
> #+attr_latex: :options {german}
>
> #+begin_foreigndisplayquote
> some text in German...
> #+end_foreigndisplayquote
>
> Are there use cases that would be better than using special blocks as in
> the example above?
I think I have not explained well about the rationale for this patch,
sorry. The advantage (IMHO) of being able to choose between several
LaTeX environments to the export of the quote blocks has more to do with
the consistency between various output formats (and a single origin). Of
course, quotation, quoting, foreigndisplayquote and a few more can be
obtained using special blocks. But for LaTeX they are just different
styles and ways to create a quote environment. At the end of the day
they are all 'quote'. It's ok that Org has only one single quote block
that is exported indistinctly to LaTeX, html, odt, etc. (Org tends to be
format agnostic and focuses more on the logical structure of the text).
But in the case of LaTeX it would be nice if the user could choose
between several ways or formats to do quotes (in LaTeX), without
resorting to special blocks. On the other hand, the standard LaTeX
`quote' environment is already far exceeded by other more powerful
options, like the csquotes package.
Best regards,
Juan Manuel
[-- Attachment #2: 0001-ox-latex.el-add-LaTeX-attributes-to-quote-block.patch --]
[-- Type: text/x-patch, Size: 4973 bytes --]
From c2e39f5f3046d7a8e90878351b35c89656dacdfc Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Wed, 26 May 2021 23:58:05 +0200
Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
* doc/org-manual.org (Quote blocks in LaTeX export): manual updated
* etc/ORG-NEWS (Support quote blocks in LaTeX export): news updated
* 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'
---
doc/org-manual.org | 42 ++++++++++++++++++++++++++++++++++++++++++
etc/ORG-NEWS | 7 +++++++
lisp/ox-latex.el | 22 ++++++++++++++++++++--
3 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 118d97e0e..dd51df27e 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13919,6 +13919,48 @@ To eat the world’s due, by the grave and thee.
,#+END_VERSE
#+end_src
+*** Quote blocks in LaTeX export
+:PROPERTIES:
+:DESCRIPTION: Attributes specific to quote blocks.
+:END:
+
+#+cindex: quote blocks, in @LaTeX{} export
+#+cindex: @samp{ATTR_LATEX}, keyword
+#+cindex: org-latex-default-quote-environment
+
+The LaTeX export back-end accepts two attributes for quote blocks:
+=:environment=, for an arbitrary quoting environment (the default
+value is that of =org-latex-default-quote-environment=: ="quote"=) and
+=:options=. For example, to choose the environment =quotation=,
+included as an alternative to =quote= in standard LaTeX classes:
+
+#+begin_example
+,#+ATTR_LATEX: :environment quotation
+,#+BEGIN_QUOTE
+some text...
+,#+END_QUOTE
+#+end_example
+
+To choose the =foreigndisplayquote= environment, included in the LaTeX
+package =csquotes=, with the =german= option, use this syntax:
+
+#+begin_example
+,#+LATEX_HEADER:\usepackage[autostyle=true]{csquotes}
+,#+ATTR_LATEX: :environment foreigndisplayquote :options {german}
+,#+BEGIN_QUOTE
+some text in German...
+,#+END_QUOTE
+#+end_example
+
+#+texinfo: @noindent
+which is exported to LaTeX as
+
+#+begin_example
+\begin{foreigndisplayquote}{german}
+some text in German...
+\end{foreigndisplayquote}
+#+end_example
+
** Markdown Export
:PROPERTIES:
:DESCRIPTION: Exporting to Markdown.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 8707222e0..c8a93c933 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -244,6 +244,13 @@ require the external LaTeX package =verse.sty=, wich is an extension
of the standard LaTeX environment. The purpose of these attributes is
explained below.
+*** Support quote blocks in LaTeX export
+
+The LaTeX export back-end accepts two attributes for quote blocks:
+=:environment=, for an arbitrary quoting environment (the default
+value is that of =org-latex-default-quote-environment=: ="quote"=) and
+=:options=.
+
*** =org-set-tags-command= selects tags from ~org-global-tags-completion-table~
Let ~org-set-tags-command~ TAB fast tag completion interface complete
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index b9ecf070a..9e2e7be47 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,9 +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 6%]
* Re: Smart quotes not working correctly with single quotes
@ 2021-05-28 10:10 9% ` Juan Manuel Macías
2021-05-28 15:42 7% ` Andreas Gösele
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-28 10:10 UTC (permalink / raw)
To: Andreas Gösele; +Cc: orgmode
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: Smart quotes not working correctly with single quotes
2021-05-28 10:10 9% ` Juan Manuel Macías
@ 2021-05-28 15:42 7% ` Andreas Gösele
2021-05-28 17:02 9% ` Juan Manuel Macías
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Andreas Gösele @ 2021-05-28 15:42 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
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 7%]
* Re: Smart quotes not working correctly with single quotes
2021-05-28 15:42 7% ` Andreas Gösele
@ 2021-05-28 17:02 9% ` Juan Manuel Macías
2021-05-28 20:27 7% ` Andreas Gösele
2021-05-28 17:55 0% ` Albert Krewinkel
2 siblings, 1 reply; 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: Smart quotes not working correctly with single quotes
2021-05-28 15:42 7% ` Andreas Gösele
2021-05-28 17:02 9% ` Juan Manuel Macías
@ 2021-05-28 17:55 0% ` Albert Krewinkel
2 siblings, 0 replies; 200+ results
From: Albert Krewinkel @ 2021-05-28 17:55 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Juan Manuel =?utf-8?Q?Mac=C3=ADas?=
Andreas Gösele <agoesele@sju.edu> writes:
> [...] 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.
I apologize for the non-Emacs solution, but you can use pandoc in
combination with the following Lua filter to get the desired result:
https://github.com/pandoc/lua-filters/tree/master/pandoc-quotes.lua
For LaTeX output, you can also pass -Vcsquotes as a parameter to force
pandoc to make use of the csquotes package. Both should give you the
desired results.
HTH
> 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
>>>
--
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe e836 388d c0b2 1f63 1124
^ permalink raw reply [relevance 0%]
* Re: Smart quotes not working correctly with single quotes
@ 2021-05-28 20:19 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-28 20:19 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hi Nicholas,
Nicolas Goaziou writes:
> Genuine question: what language uses two different styles of outer
> (level 1) quotes? And in what context?
I answer in the case of Spanish. In Spanish the level 1 quotes are «»
(french quotes). The level 2 are “...” (english quotes). Only in some
cases, and according to some writers and manuals, single quotation marks
‘...’ are correct as 1 level quotes (left single quotation mark ...
right single quotation mark), in short segments, generally when you want
to indicate the translation of a term. i.e.:
car (‘coche’)
Anyway, in Spanish it is not correct to use second level quotes “...” as
first-level quotes. I do not know if it is correct in German.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Smart quotes not working correctly with single quotes
2021-05-28 17:02 9% ` Juan Manuel Macías
@ 2021-05-28 20:27 7% ` Andreas Gösele
2021-05-28 20:37 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Andreas Gösele @ 2021-05-28 20:27 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Thanks Juan Manuel!
I tried it, but it doesn't work. It leaves the simple quotes
untouched. Did you test it and did it work then?
Best regards,
Andreas
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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 7%]
* Re: Smart quotes not working correctly with single quotes
2021-05-28 20:27 7% ` Andreas Gösele
@ 2021-05-28 20:37 10% ` Juan Manuel Macías
2021-05-29 2:42 6% ` Andreas Gösele
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-28 20:37 UTC (permalink / raw)
To: Andreas Gösele; +Cc: orgmode
Hi Andreas,
Andreas Gösele writes:
> I tried it, but it doesn't work. It leaves the simple quotes
> untouched. Did you test it and did it work then?
I forgot to tell you (sorry!) that you should set the variable
`org-export-allow-bind-keywords' as non-nil:
(setq org-export-allow-bind-keywords t)
If you are going to use that filter in many documents, you can better add to your
~ /.emacs:
(add-to-list 'org-export-filter-final-output-functions 'single-quote-filter)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Smart quotes not working correctly with single quotes
2021-05-28 20:37 10% ` Juan Manuel Macías
@ 2021-05-29 2:42 6% ` Andreas Gösele
0 siblings, 0 replies; 200+ results
From: Andreas Gösele @ 2021-05-29 2:42 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Andreas Gösele writes:
>
>> I tried it, but it doesn't work. It leaves the simple quotes
>> untouched. Did you test it and did it work then?
>
> I forgot to tell you (sorry!) that you should set the variable
> `org-export-allow-bind-keywords' as non-nil:
>
> (setq org-export-allow-bind-keywords t)
With this the filter works. Thanks a lot.
Andreas
^ permalink raw reply [relevance 6%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-26 23:02 6% ` Juan Manuel Macías
@ 2021-05-29 20:22 6% ` Nicolas Goaziou
0 siblings, 0 replies; 200+ results
From: Nicolas Goaziou @ 2021-05-29 20:22 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I'm sorry, it's my fault. It's already fixed. I think the patch attached
> here should apply well...
Applied. Thank you.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* Re: TMIO Pre-release, request for feedback
@ 2021-05-30 19:42 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-30 19:42 UTC (permalink / raw)
To: Timothy; +Cc: orgmode
Hi Timothy,
Timothy writes:
> Hi Everyone,
>
> As we arrive at the end of May, I'm about to publish the 3rd issue of
> /This Month in Org/. I thought I'd share the current draft with the list
> the day before I publish to so that those of you who are interested have
> the chance to point out any errors, let me know if there's anything I
> haven't covered that you'd like to see, along with any other feedback
> you may have.
>
> For the next day, you can find the draft at:
> https://blog.tecosaur.com/tmio/DRAFT-2021-05-31.html
> and then once published it will live at:
> https://blog.tecosaur.com/tmio/2021-05-31.html
Thank you very much for your excellent work, and for all the effort and
time you put in it. I think your /This Month in Org/ conveys, above all,
something very valuable that all Org users share: an immense and
uncompromising enthusiasm for Org and Emacs :-D
I like the design of the site: very clear and readable.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* An attempt to convert Elfeed entries (with parameters) to Org trees
@ 2021-05-31 10:40 9% Juan Manuel Macías
2021-06-23 14:56 6% ` Ihor Radchenko
0 siblings, 1 reply; 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%]
* Re: suggestion to change default org-latex-pdf-process to latexmk
@ 2021-06-01 15:52 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-01 15:52 UTC (permalink / raw)
To: Bruce D'Arcus; +Cc: orgmode
Hi Bruce,
Bruce D'Arcus writes:
> So what do LaTeX users think about changing the default for
> "org-latex-pdf-process" to "latexmk"?
It sounds like a good idea to me. In fact I have `org-latex-pdf-process'
set to latexmk in my ~ /.emacs (with the option to always compile with
LuaTeX).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: suggestion to change default org-latex-pdf-process to latexmk
@ 2021-06-02 8:40 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-02 8:40 UTC (permalink / raw)
To: Stefan Nobis; +Cc: orgmode
Stefan Nobis writes:
> An alternative may be to use latexmk only if citations are found (new
> feature, new dependencies). Or a wrapper that checks whether latexmk
> is available and works (e.g. trying to call "latexmk --version") and
> falls back to the old routine of manually running the engine and
> bibtex/biber if necessary.
Another possibility would be to add to the documentation all the
instructions needed on how to properly configure `org-latex-pdf-process'
with latexmk, for those users who wish to use bibtex or biblatex.
Although latexmk is also useful for many packages that need multiple
compilations, indexes, etc.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Format babel code block for export?
@ 2021-06-02 9:42 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-02 9:42 UTC (permalink / raw)
To: Galaxy Being; +Cc: orgmode
Hi Lawrence,
You can use multiple blocks and noweb reference syntax
(https://orgmode.org/manual/Noweb-Reference-Syntax.html):
#+NAME:block1
#+begin_src haskell :results silent :exports none
:{
#+end_src
#+NAME:block2
#+begin_src haskell :results silent :exports none
maximum'' :: (Ord a) => [a] -> a
maximum'' = foldl1 (\x acc -> if x > acc then x else acc)
#+end_src
#+NAME:block3
#+begin_src haskell :results silent :exports none
:}
#+end_src
# for export
#+begin_src haskell :noweb yes :exports code
<<block2>>
#+end_src
# for evaluation
#+begin_src haskell :noweb yes :results silent :exports none
<<block1>>
<<block2>>
<<block3>>
#+end_src
Best regards,
Juan Manuel
Galaxy Being <borgauf@gmail.com> writes:
> I have this
>
> #+begin_src haskell :results silent :exports code
> :{
> maximum'' :: (Ord a) => [a] -> a
> maximum'' = foldl1 (\x acc -> if x > acc then x else acc)
> :}
> #+end_src
>
> but on export to HTML (or LaTex) I'd like to suppress the :{ and :} to
> just show the code
>
> maximum'' :: (Ord a) => [a] -> a
> maximum'' = foldl1 (\x acc -> if x > acc then x else acc)
>
> Also, this
>
> #+begin_src haskell :results verbatim :exports both
> maximum'' [1,3,5,2,4]
> #+end_src
>
> I'd like to export the code part with a > REPL prompt included, e.g.,
>
>> maximum'' [1,3,5,2,4]
>
> I once saw some similar tricks, but I've searched and searched and
> can't find them again. There's probably other html export formatting
> I'd like too, but if anyone can point me to that mystery doc I'd
> appreciate it.
>
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf@gmail.com
>
^ permalink raw reply [relevance 10%]
* Remove all Org metadata with header argument `:comments org'
@ 2021-06-03 14:54 10% Juan Manuel Macías
2021-06-20 13:58 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-03 14:54 UTC (permalink / raw)
To: orgmode
I am writing an *.el file from an *.org file (and then I run
org-babel-tangle). With the header argument `:comments org' not only the
text in my org file is converted to comments (my desired goal) but also
the drawers, keywords and other Org metadata. Since I don't see that all
that stuff is necessary in a source file, wouldn't it be better to get
rid of it during the tangle process, leaving only pure content as
comment strings? Maybe converting the Org file content to plain text
with ox-ascii, or something like that?
What do you think?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part
@ 2021-06-03 21:11 10% Juan Manuel Macías
2021-06-04 11:31 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-03 21:11 UTC (permalink / raw)
To: orgmode
Hi all,
In master:
if I do:
(org-link-set-parameters "foo"
:display 'full
:face '(:foreground "chocolate" :weight bold :underline t))
and then:
[[foo:target][description]]
the face parameter is only applied in the description part.
Expected result: shouldn't the face be applied to the entire link?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part
2021-06-03 21:11 10% [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part Juan Manuel Macías
@ 2021-06-04 11:31 13% ` Juan Manuel Macías
2021-06-06 22:34 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-04 11:31 UTC (permalink / raw)
To: orgmode
Hello again,
To simplify what I mentioned in my previous message, the bug is simply
reproducible with any link, when running `org-toggle-link-display'.
I'm not sure, but I would say it was introduced in the commit:
8bdcf51ac lisp/org.el: Update previews correctly when color chnages
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Hi all,
>
> In master:
>
> if I do:
>
> (org-link-set-parameters "foo"
> :display 'full
> :face '(:foreground "chocolate" :weight bold :underline t))
>
> and then:
>
> [[foo:target][description]]
>
> the face parameter is only applied in the description part.
>
> Expected result: shouldn't the face be applied to the entire link?
>
> Best regards,
>
> Juan Manuel
>
^ permalink raw reply [relevance 13%]
* Re: [PATCH] Allow LaTeX reference command (\ref) to be customised
@ 2021-06-06 18:29 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-06 18:29 UTC (permalink / raw)
To: Timothy; +Cc: orgmode
Hi Timothy,
Timothy writes:
> I've started doing some more cross-referencing in documents exported to
> LaTeX, and a hardcoded use of \ref has begun to stand out to me as a
> rather annoying thing. Hypperef provides \autoref for adding helpful
> prefixes (section, figure, etc.), and there are other packages which one
> may want to use to generate 'clever' references (like cleveref with
> \cref).
>
> As such, I think that the hardcoded \ref should actually be turned into
> a customisable format string, which is what the attached patch does.
I think it's a great idea. There are many options in LaTeX to manage
cross references, beyond the standar \ref. I use the varioref package a
lot (https://www.ctan.org/pkg/varioref).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part
2021-06-04 11:31 13% ` Juan Manuel Macías
@ 2021-06-06 22:34 13% ` Juan Manuel Macías
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
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-06 22:34 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> To simplify what I mentioned in my previous message, the bug is simply
> reproducible with any link, when running `org-toggle-link-display'.
>
> I'm not sure, but I would say it was introduced in the commit:
>
> 8bdcf51ac lisp/org.el: Update previews correctly when color chnages
I correct myself. I think the commit where this problem was introduced is:
979e82fc3 Make sure that headline faces take precedence
Best regards,
Juan Manuel
^ permalink raw reply [relevance 13%]
* Re: literate programming, development log -- ideas?
@ 2021-06-07 12:00 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-07 12:00 UTC (permalink / raw)
To: Greg Minshall; +Cc: orgmode
Hi Greg,
Greg Minshall writes:
> but i also feel a need for something that might be called a lab
> notebook, a development log, of ideas, including dead ends, i pursue
> during the development process, with links, etc.. but, i'm not really
> sure how to structure this bit, how to integrate it in the rest of the
> .org file -- i.e., as a separate heading, or related to the code section
> that (originally) was under development when the notes were created.
> or...? etc.
I use `org-add-note' a lot, in a wide variety of scenarios. According to their
docstring:
"Add a note to the current entry.
This is done in the same way as adding a state change note."
And I've set (setq org-log-into-drawer t)
On the other hand, maybe you can find interesting the org-marginalia package:
(https://github.com/nobiot/org-marginalia).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* org-critical-edition (a package for philologists and classicists)
@ 2021-06-07 13:09 10% Juan Manuel Macías
2021-06-14 8:50 6% ` Christian Moe
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-07 13:09 UTC (permalink / raw)
To: orgmode
Hi all,
I have uploaded the (very) initial version of my package
org-critical-edition:
https://gitlab.com/maciaschain/org-critical-edition
This package lets you prepare a philological critical edition in Org
Mode. The natural output is LaTeX with the reledmac package
(https://www.ctan.org/pkg/reledmac).
(For those who are not philologists, this is an example of critical
edition that I typesetted recently: https://imgur.com/a/drqCib5)
Feedback welcome!
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.)
2021-06-06 22:34 13% ` Juan Manuel Macías
@ 2021-06-08 0:24 9% ` Juan Manuel Macías
2021-09-26 6:08 6% ` Bastien
0 siblings, 1 reply; 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] Re: org-attach a directory?
@ 2021-06-09 1:38 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-09 1:38 UTC (permalink / raw)
To: John Kitchin; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 786 bytes --]
Hi John,
John Kitchin writes:
> I want to attach all the files in a directory on my desktop to the
> attachment directory, something that is more like
> org-attach-attach-mv-directory (that is not an existing command, but
> what I was thinking of doing). Did I misunderstand what
> org-attach-set-directory does?
As far as I know, that option is not possible. And it's something that
I've always missed in org-attach. I've written this possible patch, with
two new attach methods/commands to copy or move a directory ("C" and
"M"). I guess it would be better to use `read-file-name' and
`read-directory-name' according to each case, but I can't think of how
to solve that. Anyway, `read-file-name' may also apply here for
directories.
(Little tested).
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Org-attach.el-Add-two-new-methods-for-cp-or-mv-directories.patch --]
[-- Type: text/x-patch, Size: 4462 bytes --]
From 5a2f59a74c9b3f8ff1cf25777067780400f9043f Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Wed, 9 Jun 2021 03:03:50 +0200
Subject: [PATCH] Org-attach.el: Add two new methods for copying or moving
directories
* lisp/org-attach.el (org-attach-commands): add two new attachments
commands
(org-attach-attach): add two new attachment methods, argument `file'
is ranamed as `target'
(org-attach-attach-cp-dir): copy a directory
(org-attach-attach-mv-dir): move (rename) a directory
---
lisp/org-attach.el | 37 +++++++++++++++++++++++++++----------
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 715fe3e93..50b1dca3b 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -199,6 +199,10 @@ git-functionality from this file.")
"Attach a file using copy method.")
((?m ?\C-m) org-attach-attach-mv
"Attach a file using move method.")
+ ((?C ?\C-C) org-attach-attach-cp-dir
+ "Attach a directory using copy dir method.")
+ ((?M ?\C-M) org-attach-attach-mv-dir
+ "Attach a directory using move dir method.")
((?l ?\C-l) org-attach-attach-ln
"Attach a file using link method.")
((?y ?\C-y) org-attach-attach-lns
@@ -489,8 +493,8 @@ if it would overwrite an existing filename."
(with-temp-file output
(insert-buffer-substring buffer-name))))
-(defun org-attach-attach (file &optional visit-dir method)
- "Move/copy/link FILE into the attachment directory of the current outline node.
+(defun org-attach-attach (target &optional visit-dir method)
+ "Move/copy/link TARGET into the attachment directory of the current outline node.
If VISIT-DIR is non-nil, visit the directory with dired.
METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from
`org-attach-method'."
@@ -504,15 +508,20 @@ METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from
current-prefix-arg
nil))
(setq method (or method org-attach-method))
- (let ((basename (file-name-nondirectory file)))
+ (let ((basename (if (or (eq method 'mv-dir)
+ (eq method 'cp-dir))
+ target
+ (file-name-nondirectory target))))
(let* ((attach-dir (org-attach-dir 'get-create))
(attach-file (expand-file-name basename attach-dir)))
(cond
- ((eq method 'mv) (rename-file file attach-file))
- ((eq method 'cp) (copy-file file attach-file))
- ((eq method 'ln) (add-name-to-file file attach-file))
- ((eq method 'lns) (make-symbolic-link file attach-file))
- ((eq method 'url) (url-copy-file file attach-file)))
+ ((eq method 'mv) (rename-file target attach-file))
+ ((eq method 'cp) (copy-file target attach-file))
+ ((eq method 'mv-dir) (rename-file target (concat attach-dir "/")))
+ ((eq method 'cp-dir) (copy-directory target (concat attach-dir "/")))
+ ((eq method 'ln) (add-name-to-file target attach-file))
+ ((eq method 'lns) (make-symbolic-link target attach-file))
+ ((eq method 'url) (url-copy-file target attach-file)))
(run-hook-with-args 'org-attach-after-change-hook attach-dir)
(org-attach-tag)
(cond ((eq org-attach-store-link-p 'attached)
@@ -520,8 +529,8 @@ METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from
(file-name-nondirectory attach-file))
org-stored-links))
((eq org-attach-store-link-p t)
- (push (list (concat "file:" file)
- (file-name-nondirectory file))
+ (push (list (concat "file:" target)
+ (file-name-nondirectory target))
org-stored-links))
((eq org-attach-store-link-p 'file)
(push (list (concat "file:" attach-file)
@@ -539,6 +548,14 @@ METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from
"Attach a file by moving (renaming) it."
(interactive)
(let ((org-attach-method 'mv)) (call-interactively 'org-attach-attach)))
+(defun org-attach-attach-cp-dir ()
+ "Attach a directory by copying it."
+ (interactive)
+ (let ((org-attach-method 'cp-dir)) (call-interactively 'org-attach-attach)))
+(defun org-attach-attach-mv-dir ()
+ "Attach a directory by moving (renaming) it."
+ (interactive)
+ (let ((org-attach-method 'mv-dir)) (call-interactively 'org-attach-attach)))
(defun org-attach-attach-ln ()
"Attach a file by creating a hard link to it.
Beware that this does not work on systems that do not support hard links.
--
2.31.1
^ permalink raw reply related [relevance 6%]
* Re: org-attach a directory?
@ 2021-06-10 14:01 10% ` Juan Manuel Macías
2021-06-10 16:13 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-10 14:01 UTC (permalink / raw)
To: Christian Barthel, John Kitchin, Ihor Radchenko; +Cc: orgmode
This only works when you create the attach folder manually, but not when
you want org-attach to generate the attach directory for the current
node.
If I have to stay with a workaround that covers many scenarios, I would
stay with Ihor's snippet, which seems to me simpler than the patch that
I suggested before, and you don't need to define new attach
commands/methods. I would vote for a patch in that direction (Ihor's
code).
Best regards,
Juan Manuel
Christian Barthel writes:
> On Thu, Jun 10 2021, Ypo wrote:
>
>> C-c C-a
>>
>> s
>>
>> (not "S" like in the video, but "s")
>
> Thanks, that is an interesting workaround:
> Setting the directory twice and using the copy/delete action
> accordingly.
>
> Does anyone know if there is a workaround to attach a file and
> delete the old one (or move the file) or do I need to write a
> small elisp function for that?
^ permalink raw reply [relevance 10%]
* Re: org-attach a directory?
2021-06-10 14:01 10% ` Juan Manuel Macías
@ 2021-06-10 16:13 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-10 16:13 UTC (permalink / raw)
To: orgmode
You could also modify some line in org-attach-attach, for example:
...
((eq method 'cp) (if (file-directory-p file)
(copy-directory file attach-file)
(copy-file file attach-file)))
...
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> If I have to stay with a workaround that covers many scenarios, I would
> stay with Ihor's snippet, which seems to me simpler than the patch that
> I suggested before, and you don't need to define new attach
> commands/methods. I would vote for a patch in that direction (Ihor's
> code).
^ permalink raw reply [relevance 13%]
* Re: literate programming, development log -- ideas? (ominbus reply)
@ 2021-06-11 14:30 10% ` Juan Manuel Macías
2021-06-11 15:02 6% ` Samuel Banya
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-11 14:30 UTC (permalink / raw)
To: Samuel Banya; +Cc: orgmode
Samuel Banya writes:
> I'm okay with git repos for dot files or some kind of programming
> project but yeah, I've been debating something else for an org based
> repo cause I too have almost had my 'life.org' be completely destroyed
> with a merge event.
I have all my everyday Org documents in a Nextcloud folder, but only
because I work between the desktop PC and the laptop. I sync using a
script with nextcloud-cmd, not via the Nextcloud app, which I find it
somewhat intrusive. And with another script I do every week a backup of
that folder to a git repo. But this repo is secondary and is only for
keep some backups (I also keep a weekly backup of Elpa folders ---last
versions--- there, in case some update breaks something).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: literate programming, development log -- ideas? (ominbus reply)
2021-06-11 14:30 10% ` Juan Manuel Macías
@ 2021-06-11 15:02 6% ` Samuel Banya
0 siblings, 0 replies; 200+ results
From: Samuel Banya @ 2021-06-11 15:02 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Charles Berry
[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]
Now this idea I like!
Thanks for this, I didn't think about using the Git repo as a SECONDARY backup source.
Also, using Nextcloud sounds like a neat idea.
I'm into Self-Hosting stuff myself nowadays but am starting out small (ex: Just bought an old Dell Optiplex from eBay, put 2 HDDs into it, planning on using it for HDD backups, and as a Git server).
However, this sounds like an awesome workflow, as I did not consider to host Nextcloud. Awesome idea, thank you for this, Juan!
On Fri, Jun 11, 2021, at 10:30 AM, Juan Manuel Macías wrote:
> Samuel Banya writes:
>
> > I'm okay with git repos for dot files or some kind of programming
> > project but yeah, I've been debating something else for an org based
> > repo cause I too have almost had my 'life.org' be completely destroyed
> > with a merge event.
>
> I have all my everyday Org documents in a Nextcloud folder, but only
> because I work between the desktop PC and the laptop. I sync using a
> script with nextcloud-cmd, not via the Nextcloud app, which I find it
> somewhat intrusive. And with another script I do every week a backup of
> that folder to a git repo. But this repo is secondary and is only for
> keep some backups (I also keep a weekly backup of Elpa folders ---last
> versions--- there, in case some update breaks something).
>
> Best regards,
>
> Juan Manuel
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 2003 bytes --]
^ permalink raw reply [relevance 6%]
* Re: org-attach a directory?
@ 2021-06-11 17:10 4% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-11 17:10 UTC (permalink / raw)
To: John Kitchin; +Cc: orgmode
I have put the Ihor's snippet in my init file. I find it very useful,
and everything is done from a simple Helm session. The only case it
doesn't work is when I just want to copy a directory --not a file--
(instead of moving or giving it a symbolic link). So I have done this
little modification (just added a conditional to the old function when
the method attach is 'cp: if attachment is a file, run `copy-file'. If
it is a directory, run `copy-directory'. Then just call the org-attach
dispatcher as always: C-c C-a and select an attach method:
(define-advice org-attach-attach (:around (oldfun files &rest args) start-from-default-directory)
"Code shared by Ihor Radchenko, slightly modified and adapted to my use."
(interactive
(list
(mapcar #'directory-file-name (helm-read-file-name "File to keep as an attachment:"
:initial-input (or (progn
(require 'dired-aux)
(dired-dwim-target-directory))
default-directory)
:marked-candidates t))
current-prefix-arg
nil))
;; my addition starts here
(setq oldfun (lambda (file &optional visit-dir method)
(interactive)
(setq method (or method org-attach-method))
(let ((basename (file-name-nondirectory file)))
(let* ((attach-dir (org-attach-dir 'get-create))
(attach-file (expand-file-name basename attach-dir)))
(cond
((eq method 'mv) (rename-file file attach-file))
((eq method 'cp) (if (file-directory-p file) (ref:lin-attach)
(copy-directory file attach-file)
(copy-file file attach-file)))
((eq method 'ln) (add-name-to-file file attach-file))
((eq method 'lns) (make-symbolic-link file attach-file))
((eq method 'url) (url-copy-file file attach-file)))
(run-hook-with-args 'org-attach-after-change-hook attach-dir)
(org-attach-tag)
(cond ((eq org-attach-store-link-p 'attached)
(push (list (concat "attachment:" (file-name-nondirectory attach-file))
(file-name-nondirectory attach-file))
org-stored-links))
((eq org-attach-store-link-p t)
(push (list (concat "file:" file)
(file-name-nondirectory file))
org-stored-links))
((eq org-attach-store-link-p 'file)
(push (list (concat "file:" attach-file)
(file-name-nondirectory attach-file))
org-stored-links)))
(if visit-dir
(dired attach-dir)
(message "File or directory %S is now an
attachment" basename))))))
;; my addition ends here
(unless (listp files) (setq files (list files)))
(mapc (lambda (file) (apply oldfun file args)) files))
John Kitchin writes:
> I discovered another way to do this that is already built in with
> `org-attach-dired-to-subtree` that would help sometimes.
>
> You split your window, open dired in one of them, mark some files, and
> then run that command in the dired window.
>
> John
>
> -----------------------------------
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
> On Thu, Jun 10, 2021 at 10:04 PM stardiviner <numbchild@gmail.com>
> wrote:
>
> I want this feature patch too. Hope Org Mode can add this. I
> remember old version org-mode can do this. But later delete this
> feature? I forget what version is.
>
> I suggest to add this feature.
>
> On Jun 8, 2021, at 11:49 PM, John Kitchin
> <jkitchin@andrew.cmu.edu> wrote:
>
> Is it possible to attach a directory to an org heading?
>
> I have only seen how to attach a file so far.
>
> John
>
> -----------------------------------
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
--
^ permalink raw reply [relevance 4%]
* Re: Failure to resolve internal links on ox-html export?
@ 2021-06-11 18:31 10% ` Juan Manuel Macías
2021-06-18 19:47 6% ` Tim Visher
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-11 18:31 UTC (permalink / raw)
To: Tim Visher; +Cc: orgmode
Hi Tim,
Try setting this variable to non-nil:
(setq org-export-with-broken-links t)
Best regards,
Juan Manuel
Tim Visher writes:
> Hi Everyone,
>
> I'd like to be able to link to various areas of a large wiki file I
> maintain for when I'm looking at an entry in emacs. However, I will
> often email exported subtrees and when I do that if I have a link to a
> heading that's outside the current subtree it fails with a
> `user-error: Unable to resolve link: …`, I assume because the export
> tree doesn't contain that heading.
>
> Is there any way to tell the exporter to simply make those into plain
> text _or_ to simply ignore the error?
>
> Thanks in advance!
>
> --
>
> In Christ,
>
> Timmy V.
>
> https://blog.twonegatives.com
> http://five.sentenc.es
>
^ permalink raw reply [relevance 10%]
* Re: Write Markdown in Org mode
@ 2021-06-12 12:35 9% ` Juan Manuel Macías
2021-06-12 15:14 6% ` leo
0 siblings, 1 reply; 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%]
* Re: Write Markdown in Org mode
2021-06-12 12:35 9% ` Juan Manuel Macías
@ 2021-06-12 15:14 6% ` leo
2021-06-12 15:51 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: leo @ 2021-06-12 15:14 UTC (permalink / raw)
To: orgmode
Gi Juan
On 12 Jun 2021, at 22:35, Juan Manuel Macías wrote:
> 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
Good to know. I’m not too keen to learn yet another text markup language, but I might give org mode a try…
Leo
^ permalink raw reply [relevance 6%]
* Re: Write Markdown in Org mode
2021-06-12 15:14 6% ` leo
@ 2021-06-12 15:51 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-12 15:51 UTC (permalink / raw)
To: leo; +Cc: orgmode
Hi Leo,
leo writes:
> Good to know. I’m not too keen to learn yet another text markup language, but I might give org mode a try…
It's worth a try! Org markup language is very similar to Markdown. My
advice is that you take from Org only what you need, because Org has so
many features that at first it can saturate you. A Recommended initial
reading may be the compact guide, which gives you a pretty global vision
without going too deep in each aspect: https://orgmode.org/guide/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [tip] LaTeX preview of a region
@ 2021-06-12 23:51 7% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-12 23:51 UTC (permalink / raw)
To: orgmode
Hi all,
When typesetting a long book, I often need to fine tune many paragraphs
(typographically speaking). So I've write this code to avoid compiling
the whole document every time. The idea is activate a preview of any
region of the document, compiled with all the local configuration
(export filters, setup file, export options, etc.). In other words, the
preview *must be identical* to the compiled/exported pdf. Although it is
for a particular use case, I share it here in case it is useful to
someone.
My intention is to give these four variables a local value for each
document or major project. But this would be the default value:
#+begin_src emacs-lisp
(setq my-prev/preamble "preamble.tex"
my-prev/env-begin "@@latex:\\begin{dummy}@@"
my-prev/env-end "@@latex:\\end{dummy}@@"
my-prev/conf "#+OPTIONS: ':t\n
#+LANGUAGE: es\n"
#+SETUPFILE: normal.setup\n
#+INCLUDE: export-filters\n")
#+end_src
The first variable makes sense because I always use a separate file as a
preamble for large projects. The second and third variables correspond
to the environment to enclose the preview (by default, a `dummmy'
environment: `\newenvironment*{dummy}{}{}'). And the fourth is the
configuration to export the preview.
And these two functions enable or disable the preview on a region (here
a sample video:
https://lunotipia.juanmanuelmacias.com/images/latex-preview.mp4):
#+begin_src emacs-lisp
(defun my-org-latex-prev-region ()
(interactive)
(let* ((frag (save-restriction
(narrow-to-region (region-beginning) (region-end))
(buffer-string)))
(my-prev/preamble-l (buffer-local-value 'my-prev/preamble (current-buffer)))
(my-prev/env-begin-l (buffer-local-value 'my-prev/env-begin (current-buffer)))
(my-prev/env-end-l (buffer-local-value 'my-prev/env-end (current-buffer)))
(my-prev/conf-l (buffer-local-value 'my-prev/conf (current-buffer)))
(org-preview-latex-default-process 'luamagick)
(org-format-latex-header (concat (with-temp-buffer
(insert-file-contents my-prev/preamble-l)
(buffer-string)) "\n"
"\\pagestyle{empty}"))
(prev (with-temp-buffer
(insert (concat my-prev/conf-l "\n\n" my-prev/env-begin-l "\n\n" frag "\n\n" my-prev/env-end-l))
(mark-whole-buffer)
(org-latex-convert-region-to-latex)
(org-latex-preview)
(goto-char (point-min))
(overlay-get (car (overlays-at (point))) 'display))))
(let*
((ov (make-overlay (region-beginning) (region-end))))
(overlay-put ov 'overlay-latex-prev t)
(overlay-put ov 'display prev))))
(defun my-org-latex-remove-prev-region ()
(interactive)
(remove-overlays nil nil 'overlay-latex-prev t))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: org-critical-edition (a package for philologists and classicists)
2021-06-07 13:09 10% org-critical-edition (a package for philologists and classicists) Juan Manuel Macías
@ 2021-06-14 8:50 6% ` Christian Moe
2021-06-15 12:44 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Christian Moe @ 2021-06-14 8:50 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
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?
Yours,
Christian
Juan Manuel Macías writes:
> Hi all,
>
> I have uploaded the (very) initial version of my package
> org-critical-edition:
>
> https://gitlab.com/maciaschain/org-critical-edition
>
> This package lets you prepare a philological critical edition in Org
> Mode. The natural output is LaTeX with the reledmac package
> (https://www.ctan.org/pkg/reledmac).
>
> (For those who are not philologists, this is an example of critical
> edition that I typesetted recently: https://imgur.com/a/drqCib5)
>
> Feedback welcome!
>
> Best regards,
>
> Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: org-critical-edition (a package for philologists and classicists)
2021-06-14 8:50 6% ` Christian Moe
@ 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: no inline images anymore after reinstall
@ 2021-06-16 12:51 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-16 12:51 UTC (permalink / raw)
To: Prof. Dr. Johanna May; +Cc: orgmode
Hi Johanna,
I don't have much knowledge of Python, but I have done this, in case it
helps you locate the problem:
- I have tried to evaluate your block (previously I have installed in my
Arch system python-matplotlib). Output:
#+RESULTS: fig-zeitverlaufspgendrehstrom
[[file:]]
but
- I have noticed that if you comment on these two lines:
# plt.rcParams.update({'font.size':fontsize})
# rcParams.update({'figure.autolayout': True})
output:
#+RESULTS: fig-zeitverlaufspgendrehstrom
[[file:/tmp/babel-yXFqLG/figurepLRhLV.png]]
(Python console was returning these two errors before commenting
the lines:
NameError: name 'fontsize' is not defined
NameError: name 'rcParams' is not defined)
Best regards,
Juan Manuel
Prof. Dr. Johanna May writes:
> Hi guys,
>
> I've been trying on the web and in "known as good" config files to solve
> this but cannot seem to find the solution:
>
> After reinstalling linux (openSuse leap 15.3) and finding out that
> unfortunately the distro is too new, so 27.1 does not yet get offered
> and switching back to 25.3 most of the stuff that I need works again.
>
> Except for including python output diagrams in org-babel. I put the
> diagram code at the very bottom since it takes up some space. At the very end
> you also see the output: it is not a file, it is just a link called
> [[file:]]. That cannot be right and then, of course, there are no inline
> images displayed and not exported either. It is remarkable though, that
> latex gets the link to the file, but just does not seem to show it
> right. This might point to a latex problem, but the inline images aren't
> shown in org-babel. Therefore I'm trying to find a solution here.
>
> In my dotemacs I included what I thought relevant to get it working, but
> it doesn't (below).
>
> I would be very glad about a hint where to look for a solution. Maybe
> some package-install (but which). Or some other configuration ... Or
> maybe I'm still lacking an important distro package that just does not
> get output on any error buffer?
>
> Thank you very much, any help is appreciated
>
> Johanna May
>
> --- some of my dotemacs lines ---
> ;; === org-babel - Code einbinden ===
> ;; ### Darstellung ###
> (setq org-startup-with-inline-images t)
> (setq org-confirm-babel-evaluate nil)
> (setq org-src-fontify-natively t)
> (setq org-src-tab-acts-natively t)
> (setq org-hide-emphasis-markers t)
>
> ;; ### Statistik mit R ESS ###
> (require 'ess-site)
>
> ;; ### org-babel Sprachen ###
> (require 'ob-python)
> (setq org-babel-python-command "python3")
> ;;(setq python-shell-interpreter "python3")
> (org-babel-do-load-languages
> 'org-babel-load-languages
> '((emacs-lisp . t)
> (python . t)
> (ipython . t)
> (shell . t)
> (js . t)
> (latex . t)
> (org . t)
> (octave . t)
> (R . t)
> (plantuml . t)
> (dot . t)
> (gnuplot . t)
> (ruby . t)
> (screen . nil)
> (ledger . t)
> (C . t)
> (sql . t)
> (ditaa . t)))
>
> ;; ### Einrückungen beachten (z. B. python) ###
> (setq org-edit-src-content-indentation 0)
> (setq org-src-tab-acts-natively t)
> (setq org-src-preserve-indentation t)
>
> ;; ### python-Coding ###
> (require 'epc)
> (require 'company)
> (add-hook 'after-init-hook 'global-company-mode)
> (global-font-lock-mode t)
> (setq font-lock-maximum-decoration t)
> (setq-default indent-tabs-mode nil) ;; nicht Tabs sondern 4 Leerzeichen
> (setq default-tab-width 4)
> (add-hook 'python-mode-hook 'anaconda-mode)
> (add-hook 'python-mode-hook 'eldoc-mode)
> (eval-after-load "company"
> '(progn
> (add-to-list 'company-backends 'company-anaconda)))
> (add-hook 'python-mode-hook 'anaconda-mode)
>
> ;; ### Bilder aus python inline anzeigen ###
> (add-hook 'org-babel-after-execute-hook 'org-display-inline-images 'append)
> (add-hook 'org-mode-hook 'org-display-inline-images)
> --- snip ---
>
>
> ---diagram code in org---
>
> #+name: fig-zeitverlaufspgendrehstrom
> #+begin_src python :results file :session :var matplot_lib_filename=(org-babel-temp-file "figure" ".png"),fontsize=fs :exports results
>
> import matplotlib.pyplot as plt
> plt.style.use('classic')
> import numpy as np
> from matplotlib.ticker import FuncFormatter, MultipleLocator
> plt.style.use('classic')
>
> plt.rcParams.update({'font.size':fontsize})
> rcParams.update({'figure.autolayout': True})
>
> fig=plt.figure(figsize=(6,3))
>
> x=np.linspace(0,5*np.pi,1000)
> udach=230*np.sqrt(2)
> phi1=0
> phi2=-np.pi*2/3
> phi3=-np.pi*4/3
> u1=udach*np.cos(x+phi1)
> u2=udach*np.cos(x+phi2)
> u3=udach*np.cos(x+phi3)
>
> plt.plot(x,u1,label='$u_1(t)$')
> plt.plot(x,u2,label='$u_2(t)$')
> plt.plot(x,u3,label='$u_3(t)$')
> plt.xlabel('$t$')
> plt.ylabel('$u$')
> plt.xticks([])
> plt.yticks([])
> plt.legend(fontsize='small',bbox_to_anchor=(0,1.02,1.02,0),loc=3,ncol=3,mode="expand",borderaxespad=0.)
> plt.grid(True)
> plt.axhline(0,color='black',lw=1)
>
> #plt.tight_layout()
> plt.savefig(matplot_lib_filename,bbox_inches='tight')
> matplot_lib_filename
> #+end_src
>
> #+CAPTION: Zeitverlauf symmetrischer Spannungen
> #+LABEL: fig-zeitverlaufspgendrehstrom
>
> #+ATTR_LATEX: :width \textwidth :height \textheight :options angle=0,keepaspectratio :float nil
>
> #+RESULTS: fig-zeitverlaufspgendrehstrom
> [[file:]]
>
> ---snip ---
>
^ permalink raw reply [relevance 9%]
* Re: example paper written in org completely
@ 2021-06-17 12:51 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-17 12:51 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Hi Eric,
Eric S Fraga writes:
> Dear all,
>
> for those that may be interested, my latest paper (well, preprint at
> this stage) is available if you are looking for an example of a
> numerical work where the paper is completely written in org, including
> data analysis and visualisation. See signature for link.
>
> The arxiv deposit includes the complete org file as an ancillary file.
Congratulations. Thanks for sharing your work.
By the way, I think it would be nice to create on the Worg website a
section called "Org Showcase" or similar, just like there is a "Tex
Showcase" on the Tex User Group website: http://tug.org/texshowcase/,
with samples of published books, articles or web pages, all written in
Org, to demonstrate the productivity of Org Mode.
What do you think?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* A dictionary made in Org Mode
@ 2021-06-18 12:11 9% Juan Manuel Macías
2021-06-18 12:19 6% ` John Kitchin
` (2 more replies)
0 siblings, 3 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: A dictionary made in Org Mode
2021-06-18 12:11 9% A dictionary made in Org Mode Juan Manuel Macías
@ 2021-06-18 12:19 6% ` John Kitchin
2021-06-18 12:27 6% ` Detlef Steuer
2021-06-18 13:51 6% ` Samuel Banya
2 siblings, 0 replies; 200+ results
From: John Kitchin @ 2021-06-18 12:19 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
Congratulations! That looks like an amazing project.
On Fri, Jun 18, 2021 at 8:11 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> 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
>
>
> --
John
-----------------------------------
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
[-- Attachment #2: Type: text/html, Size: 2124 bytes --]
^ permalink raw reply [relevance 6%]
* Re: A dictionary made in Org Mode
2021-06-18 12:11 9% A dictionary made in Org Mode Juan Manuel Macías
2021-06-18 12:19 6% ` John Kitchin
@ 2021-06-18 12:27 6% ` Detlef Steuer
2021-06-18 13:51 6% ` Samuel Banya
2 siblings, 0 replies; 200+ results
From: Detlef Steuer @ 2021-06-18 12:27 UTC (permalink / raw)
To: emacs-orgmode
Congratulations! Looks just beautyful!
Detlef
Am Fri, 18 Jun 2021 12:11:19 +0000
schrieb Juan Manuel Macías <maciaschain@posteo.net>:
> 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 6%]
* Re: A dictionary made in Org Mode
2021-06-18 12:11 9% A dictionary made in Org Mode Juan Manuel Macías
2021-06-18 12:19 6% ` John Kitchin
2021-06-18 12:27 6% ` Detlef Steuer
@ 2021-06-18 13:51 6% ` Samuel Banya
2 siblings, 0 replies; 200+ results
From: Samuel Banya @ 2021-06-18 13:51 UTC (permalink / raw)
To: Charles Berry
[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]
Wow, that publication looks pro!
Absolutely beautiful!
On Fri, Jun 18, 2021, at 8:11 AM, Juan Manuel Macías wrote:
> 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
>
>
>
[-- Attachment #2: Type: text/html, Size: 1782 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Failure to resolve internal links on ox-html export?
2021-06-11 18:31 10% ` Juan Manuel Macías
@ 2021-06-18 19:47 6% ` Tim Visher
2021-06-18 20:37 10% ` Juan Manuel Macías
2021-06-18 22:18 0% ` Tim Cross
0 siblings, 2 replies; 200+ results
From: Tim Visher @ 2021-06-18 19:47 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 935 bytes --]
Hi Juan Manuel,
On Fri, Jun 11, 2021 at 2:31 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Try setting this variable to non-nil:
>
> (setq org-export-with-broken-links t)
>
Thanks for the tip here! This is definitely close to what I want. I think
I'm going to need to code up something additional though in that none of
the default options (mark or ignore) are really the behavior that I want.
- mark: I don't like the way the text comes out here. I don't want to have
BROKEN LINK in the exported text at all.
- ignore: I don't like how the text of the link simply disappears in this
case.
What I really want is something that keeps the link text but drops the
link, essentially converting it into plain text (or stylized text if the
link text is in markup).
I'll have to play around with how to do that.
--
In Christ,
Timmy V.
https://blog.twonegatives.com
http://five.sentenc.es
[-- Attachment #2: Type: text/html, Size: 1479 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Failure to resolve internal links on ox-html export?
2021-06-18 19:47 6% ` Tim Visher
@ 2021-06-18 20:37 10% ` Juan Manuel Macías
2021-06-18 22:18 0% ` Tim Cross
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-18 20:37 UTC (permalink / raw)
To: Tim Visher; +Cc: orgmode
Hi Tim,
Tim Visher writes:
> What I really want is something that keeps the link text but drops the
> link, essentially converting it into plain text (or stylized text if
> the link text is in markup).
According to the `org-export-with-broken-links' docstring:
-----------------------------------
[...] If it is set to ‘mark’, broken links are marked as such in the
output, with a string like
[BROKEN LINK: path]
where PATH is the un-resolvable reference.
This option can also be set with the OPTIONS keyword, e.g.,
"broken-links:mark".
-----------------------------------
It's not exactly what you're looking for, but it can help you find a
solution.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Failure to resolve internal links on ox-html export?
2021-06-18 19:47 6% ` Tim Visher
2021-06-18 20:37 10% ` Juan Manuel Macías
@ 2021-06-18 22:18 0% ` Tim Cross
2021-06-20 15:01 0% ` Tim Visher
1 sibling, 1 reply; 200+ results
From: Tim Cross @ 2021-06-18 22:18 UTC (permalink / raw)
To: emacs-orgmode
Tim Visher <tim.visher@gmail.com> writes:
> Hi Juan Manuel,
>
> On Fri, Jun 11, 2021 at 2:31 PM Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Try setting this variable to non-nil:
>
> (setq org-export-with-broken-links t)
>
> Thanks for the tip here! This is definitely close to what I want. I think I'm going to need to code up something additional though in that none of the
> default options (mark or ignore) are really the behavior that I want.
>
> - mark: I don't like the way the text comes out here. I don't want to have BROKEN LINK in the exported text at all.
> - ignore: I don't like how the text of the link simply disappears in this case.
>
> What I really want is something that keeps the link text but drops the link, essentially converting it into plain text (or stylized text if the link text is in
> markup).
>
> I'll have to play around with how to do that.
Although I've never used them, I think export filters sound like they
might be what you want. Have a look at the Advanced Export configuration
section of the manual and how to define export filters. You should be
able to define an org-export-filter-link-function that will tranform
links into just the title text from the original link.
--
Tim Cross
^ permalink raw reply [relevance 0%]
* Re: publishing: no default publishing function, or symbol is not defined
@ 2021-06-19 12:48 10% ` Juan Manuel Macías
2021-06-19 18:23 5% ` Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 18:28 5% ` [External Email] " Christopher W. Ryan via General discussions about Org-mode.
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-19 12:48 UTC (permalink / raw)
To: Christopher W. Ryan; +Cc: orgmode
Hi Christopher,
Christopher W. Ryan" via "General discussions about Org-mode. writes:
> I'm making my first foray into publishing a project. I'm running GNU
> Emacs 26.2 (build 1, x86_64-w64-mingw32) of 2019-04-13, on Windows 10.
>
> I've defined a single project, just to try it out and learn.
As Christian Moe said, the function you need is
`org-html-publish-to-html'.
In case it helps, I keep this blog about typography and TeX (in spanish),
made with org-publish: https://lunotipia.juanmanuelmacias.com/index.html
The blog's public repository is at:
https://gitlab.com/maciaschain/lunotipia
And this is the org-publish configuration for the blog:
;; lunotipia
("lunotipia-notes"
;; Org files
:base-directory "~/Git/lunotipia/org/"
:base-extension "org"
;; HTML files
:publishing-directory "~/Git/lunotipia/public/"
:publishing-function org-html-publish-to-html
:recursive t
:auto-sitemap t
:sitemap-title "Textos publicados"
:sitemap-function my-sitemap-function-lunotipia
:sitemap-filename "entradas.org"
:sitemap-style list
:sitemap-sort-files anti-chronologically
:exclude "org-rss\\|theindex\\|acerca-de\.org"
:makeindex t
:html-postamble mi-postamble)
;; static files
("lunotipia-static"
:base-directory "~/Git/lunotipia/org/images/"
:base-extension "css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf"
:publishing-directory "~/Git/lunotipia/public/images/"
:recursive t
:publishing-function org-publish-attachment)
And my custom sitemap function:
(defun my-sitemap-function-lunotipia (title list)
"Return sitemap using TITLE and LIST returned by `org-blog-sitemap-format-entry'."
(concat "#+TITLE: " title "\n\n"
"#+SETUPFILE:" "~/Git/lunotipia/html-lunotipia.setup"
"\n#+SETUPFILE:" "~/Git/gnutas/macros-gnutas.setup"
"\n#+AUTHOR:" "Juan Manuel Macías"
"\n#+LANGUAGE:" "es"
"\n#+begin_archive\n"
(mapconcat (lambda (li)
(format "@@html:<li>@@ %s @@html:</li>@@" (car li)))
(seq-filter #'car (cdr list))
"\n")
"\n#+end_archive\n"
"\n#+begin_export html"
"\n<div>"
"\n<hr />"
"\n<p>"
"\n<a href=\"acerca-de.html\">Acerca de...</a>"
"\n</p></div>"
"\n<p>"
"\n<a href=\"https://maciaschain.gitlab.io/lunotipia/rss.xml\">RSS</a>"
"\n</p></div>"
"\n#+end_export\n"))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: publishing: no default publishing function, or symbol is not defined
2021-06-19 12:48 10% ` Juan Manuel Macías
@ 2021-06-19 18:23 5% ` Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 18:28 5% ` [External Email] " Christopher W. Ryan via General discussions about Org-mode.
1 sibling, 0 replies; 200+ results
From: Christopher W. Ryan via General discussions about Org-mode. @ 2021-06-19 18:23 UTC (permalink / raw)
To: orgmode
Ah, I see I wrote the :publishing-function statement incorrectly. Thanks
to both of you.
But is there not a default publishing action, that requires no explicit
:publishing-function statement? This part of the documentation says
there is:
https://orgmode.org/manual/Publishing-action.html#Publishing-action
But I gave this a try:
(setq org-publish-project-alist
'(("CaseInvestigationTrainingAndReferenceManual"
:base-directory
"E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/"
:publishing-directory
"E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/StagingArea"
:publishing-function org-html-publish-to-html)))
and I got the expected output in the expected place: a file called
"E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/StagingArea/WorkAreaForIndexingTrainingAndReferenceManual-7-June.html
However, when I add this line:
:makeindex 1
so with a non-null value of :makeindex
The output consists *only* of the index: a file called theindex.html.
It looks like the expected index to the document, but the document
itself is not generated. How do I get both?
Thanks.
--Chris
Juan Manuel Macías wrote:
> Hi Christopher,
>
> Christopher W. Ryan" via "General discussions about Org-mode. writes:
>
>> I'm making my first foray into publishing a project. I'm running GNU
>> Emacs 26.2 (build 1, x86_64-w64-mingw32) of 2019-04-13, on Windows 10.
>>
>> I've defined a single project, just to try it out and learn.
>
> As Christian Moe said, the function you need is
> `org-html-publish-to-html'.
>
> In case it helps, I keep this blog about typography and TeX (in spanish),
> made with org-publish: https://lunotipia.juanmanuelmacias.com/index.html
>
> The blog's public repository is at:
> https://gitlab.com/maciaschain/lunotipia
>
> And this is the org-publish configuration for the blog:
>
> ;; lunotipia
> ("lunotipia-notes"
> ;; Org files
> :base-directory "~/Git/lunotipia/org/"
> :base-extension "org"
> ;; HTML files
> :publishing-directory "~/Git/lunotipia/public/"
> :publishing-function org-html-publish-to-html
> :recursive t
> :auto-sitemap t
> :sitemap-title "Textos publicados"
> :sitemap-function my-sitemap-function-lunotipia
> :sitemap-filename "entradas.org"
> :sitemap-style list
> :sitemap-sort-files anti-chronologically
> :exclude "org-rss\\|theindex\\|acerca-de\.org"
> :makeindex t
> :html-postamble mi-postamble)
>
> ;; static files
> ("lunotipia-static"
> :base-directory "~/Git/lunotipia/org/images/"
> :base-extension "css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf"
> :publishing-directory "~/Git/lunotipia/public/images/"
> :recursive t
> :publishing-function org-publish-attachment)
>
> And my custom sitemap function:
>
> (defun my-sitemap-function-lunotipia (title list)
> "Return sitemap using TITLE and LIST returned by `org-blog-sitemap-format-entry'."
> (concat "#+TITLE: " title "\n\n"
> "#+SETUPFILE:" "~/Git/lunotipia/html-lunotipia.setup"
> "\n#+SETUPFILE:" "~/Git/gnutas/macros-gnutas.setup"
> "\n#+AUTHOR:" "Juan Manuel Macías"
> "\n#+LANGUAGE:" "es"
> "\n#+begin_archive\n"
> (mapconcat (lambda (li)
> (format "@@html:<li>@@ %s @@html:</li>@@" (car li)))
> (seq-filter #'car (cdr list))
> "\n")
> "\n#+end_archive\n"
> "\n#+begin_export html"
> "\n<div>"
> "\n<hr />"
> "\n<p>"
> "\n<a href=\"acerca-de.html\">Acerca de...</a>"
> "\n</p></div>"
> "\n<p>"
> "\n<a href=\"https://maciaschain.gitlab.io/lunotipia/rss.xml\">RSS</a>"
> "\n</p></div>"
> "\n#+end_export\n"))
>
> Best regards,
>
> Juan Manuel
>
^ permalink raw reply [relevance 5%]
* Re: [External Email] Re: publishing: no default publishing function, or symbol is not defined
2021-06-19 12:48 10% ` Juan Manuel Macías
2021-06-19 18:23 5% ` Christopher W. Ryan via General discussions about Org-mode.
@ 2021-06-19 18:28 5% ` Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 19:32 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Christopher W. Ryan via General discussions about Org-mode. @ 2021-06-19 18:28 UTC (permalink / raw)
To: orgmode
Oops, spoke to soon about the structure of the index. Here is a section
of theindex.html
I
Incarceration
Incarceration
Interview
Interview
Interview
Interview
Interview
Isolation
Isolation
Isolation
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?
Thanks.
--Chris
Juan Manuel Macías wrote:
> Hi Christopher,
>
> Christopher W. Ryan" via "General discussions about Org-mode. writes:
>
>> I'm making my first foray into publishing a project. I'm running GNU
>> Emacs 26.2 (build 1, x86_64-w64-mingw32) of 2019-04-13, on Windows 10.
>>
>> I've defined a single project, just to try it out and learn.
>
> As Christian Moe said, the function you need is
> `org-html-publish-to-html'.
>
> In case it helps, I keep this blog about typography and TeX (in spanish),
> made with org-publish: https://lunotipia.juanmanuelmacias.com/index.html
>
> The blog's public repository is at:
> https://gitlab.com/maciaschain/lunotipia
>
> And this is the org-publish configuration for the blog:
>
> ;; lunotipia
> ("lunotipia-notes"
> ;; Org files
> :base-directory "~/Git/lunotipia/org/"
> :base-extension "org"
> ;; HTML files
> :publishing-directory "~/Git/lunotipia/public/"
> :publishing-function org-html-publish-to-html
> :recursive t
> :auto-sitemap t
> :sitemap-title "Textos publicados"
> :sitemap-function my-sitemap-function-lunotipia
> :sitemap-filename "entradas.org"
> :sitemap-style list
> :sitemap-sort-files anti-chronologically
> :exclude "org-rss\\|theindex\\|acerca-de\.org"
> :makeindex t
> :html-postamble mi-postamble)
>
> ;; static files
> ("lunotipia-static"
> :base-directory "~/Git/lunotipia/org/images/"
> :base-extension "css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf"
> :publishing-directory "~/Git/lunotipia/public/images/"
> :recursive t
> :publishing-function org-publish-attachment)
>
> And my custom sitemap function:
>
> (defun my-sitemap-function-lunotipia (title list)
> "Return sitemap using TITLE and LIST returned by `org-blog-sitemap-format-entry'."
> (concat "#+TITLE: " title "\n\n"
> "#+SETUPFILE:" "~/Git/lunotipia/html-lunotipia.setup"
> "\n#+SETUPFILE:" "~/Git/gnutas/macros-gnutas.setup"
> "\n#+AUTHOR:" "Juan Manuel Macías"
> "\n#+LANGUAGE:" "es"
> "\n#+begin_archive\n"
> (mapconcat (lambda (li)
> (format "@@html:<li>@@ %s @@html:</li>@@" (car li)))
> (seq-filter #'car (cdr list))
> "\n")
> "\n#+end_archive\n"
> "\n#+begin_export html"
> "\n<div>"
> "\n<hr />"
> "\n<p>"
> "\n<a href=\"acerca-de.html\">Acerca de...</a>"
> "\n</p></div>"
> "\n<p>"
> "\n<a href=\"https://maciaschain.gitlab.io/lunotipia/rss.xml\">RSS</a>"
> "\n</p></div>"
> "\n#+end_export\n"))
>
> Best regards,
>
> Juan Manuel
>
^ permalink raw reply [relevance 5%]
* Re: [External Email] Re: publishing: no default publishing function, or symbol is not defined
2021-06-19 18:28 5% ` [External Email] " Christopher W. Ryan via General discussions about Org-mode.
@ 2021-06-19 19:32 9% ` Juan Manuel Macías
2021-06-22 20:26 7% ` Christopher W. Ryan via General discussions about Org-mode.
0 siblings, 1 reply; 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%]
* Re: Remove all Org metadata with header argument `:comments org'
2021-06-03 14:54 10% Remove all Org metadata with header argument `:comments org' Juan Manuel Macías
@ 2021-06-20 13:58 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2021-06-20 13:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I am writing an *.el file from an *.org file (and then I run
> org-babel-tangle). With the header argument `:comments org' not only the
> text in my org file is converted to comments (my desired goal) but also
> the drawers, keywords and other Org metadata. Since I don't see that all
> that stuff is necessary in a source file, wouldn't it be better to get
> rid of it during the tangle process, leaving only pure content as
> comment strings? Maybe converting the Org file content to plain text
> with ox-ascii, or something like that?
>
> What do you think?
You can customise org-babel-process-comment-text to something like
(lambda (string) (org-export-string-as string 'ascii t)). Untested
though.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: Failure to resolve internal links on ox-html export?
2021-06-18 22:18 0% ` Tim Cross
@ 2021-06-20 15:01 0% ` Tim Visher
0 siblings, 0 replies; 200+ results
From: Tim Visher @ 2021-06-20 15:01 UTC (permalink / raw)
To: Tim Cross; +Cc: Emacs Org Mode mailing list
[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]
On Fri, Jun 18, 2021 at 6:22 PM Tim Cross <theophilusx@gmail.com> wrote:
>
> Tim Visher <tim.visher@gmail.com> writes:
>
> > Hi Juan Manuel,
> >
> > On Fri, Jun 11, 2021 at 2:31 PM Juan Manuel Macías <
> maciaschain@posteo.net> wrote:
> >
> > Try setting this variable to non-nil:
> >
> > (setq org-export-with-broken-links t)
> >
> > Thanks for the tip here! This is definitely close to what I want. I
> think I'm going to need to code up something additional though in that none
> of the
> > default options (mark or ignore) are really the behavior that I want.
> >
> > - mark: I don't like the way the text comes out here. I don't want to
> have BROKEN LINK in the exported text at all.
> > - ignore: I don't like how the text of the link simply disappears in
> this case.
> >
> > What I really want is something that keeps the link text but drops the
> link, essentially converting it into plain text (or stylized text if the
> link text is in
> > markup).
> >
> > I'll have to play around with how to do that.
>
> Although I've never used them, I think export filters sound like they
> might be what you want. Have a look at the Advanced Export configuration
> section of the manual and how to define export filters. You should be
> able to define an org-export-filter-link-function that will tranform
> links into just the title text from the original link.
>
Thanks, Tim! I'll check them out. I hadn't heard of them before.
[-- Attachment #2: Type: text/html, Size: 2005 bytes --]
^ permalink raw reply [relevance 0%]
* Re: publishing: no default publishing function, or symbol is not defined
2021-06-19 19:32 9% ` Juan Manuel Macías
@ 2021-06-22 20:26 7% ` Christopher W. Ryan via General discussions about Org-mode.
2021-06-25 8:38 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Christopher W. Ryan via General discussions about Org-mode. @ 2021-06-22 20:26 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel--
Thanks. I understand no pages in a web document; I thought (hoped?) that
section/subsection numbers, perhaps multiple, would appear next to the
entries in the index. I will try to be more specific with the ! syntax
Any advice for how to get *both* theindex.html and my main document in
html? So far I can only get one or the other, depending on whether I
include a non-nil value for a :makeindex option.
Thanks.
--Chris
Juan Manuel Macías wrote:
> 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 7%]
* Re: An attempt to convert Elfeed entries (with parameters) to Org trees
2021-05-31 10:40 9% An attempt to convert Elfeed entries (with parameters) to Org trees Juan Manuel Macías
@ 2021-06-23 14:56 6% ` Ihor Radchenko
2021-06-24 8:02 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-06-23 14:56 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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.
> ...
> 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! :-)
What about duplicates? If you insert all the feeds from the last few
months and then update the same headline weeks later, there will overlap
between elfeed entries.
Also, there is built-in org-feed.el.
Finally, I personally save feed entries selectively using
org-capture-ref [1].
[1] https://github.com/yantar92/org-capture-ref
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: appearance of list as results from evaluating code blocks
@ 2021-06-23 19:43 10% ` Juan Manuel Macías
2021-06-23 20:03 3% ` Johannes Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-23 19:43 UTC (permalink / raw)
To: Johannes Brauer; +Cc: orgmode
Hi Johannes,
Johannes Brauer writes:
> Hi!
> Evaluating a code block containing a list expression using org-babel for elisp or Clojure, for example
> (list 1 2 3)
> I get
> #+RESULTS:
> | 1 | 2 | 3 |
> I would prefer
> #+RESULTS:
> ( 1 2 3 )
>
> Is it possible to get this.
Try
#+begin_src emacs-lisp :results raw
(list 1 2 3)
#+end_src
#+RESULTS:
(1 2 3)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: appearance of list as results from evaluating code blocks
2021-06-23 19:43 10% ` Juan Manuel Macías
@ 2021-06-23 20:03 3% ` Johannes Brauer
0 siblings, 0 replies; 200+ results
From: Johannes Brauer @ 2021-06-23 20:03 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan Manuel,
thanks, that works
Best regards
Johannes
> Am 23.06.2021 um 21:43 schrieb Juan Manuel Macías <maciaschain@posteo.net>:
>
> Hi Johannes,
>
> Johannes Brauer writes:
>
>> Hi!
>> Evaluating a code block containing a list expression using org-babel for elisp or Clojure, for example
>> (list 1 2 3)
>> I get
>> #+RESULTS:
>> | 1 | 2 | 3 |
>> I would prefer
>> #+RESULTS:
>> ( 1 2 3 )
>>
>> Is it possible to get this.
>
> Try
>
> #+begin_src emacs-lisp :results raw
> (list 1 2 3)
> #+end_src
>
> #+RESULTS:
> (1 2 3)
>
> Best regards,
>
> Juan Manuel
>
^ permalink raw reply [relevance 3%]
* Re: An attempt to convert Elfeed entries (with parameters) to Org trees
2021-06-23 14:56 6% ` Ihor Radchenko
@ 2021-06-24 8:02 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-24 8:02 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi Ihor,
Ihor Radchenko writes:
> What about duplicates? If you insert all the feeds from the last few
> months and then update the same headline weeks later, there will overlap
> between elfeed entries.
When I update a headline, all previous feeds are removed, so there is no
possibility of duplicates. As I said, I find this system very useful to
have an overview within Org of the latest updates to certain feeds, such
as new packages uploaded to CTAN. I also have an org-capture template
only for new CTAN packages, in case I see any interesting packages.
I also have a section on CTAN news in my blog about typography and TeX
(in Spanish), and I update it using that method.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: publishing: no default publishing function, or symbol is not defined
2021-06-22 20:26 7% ` Christopher W. Ryan via General discussions about Org-mode.
@ 2021-06-25 8:38 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-25 8:38 UTC (permalink / raw)
To: Christopher W. Ryan; +Cc: orgmode
Hi Christopher, sorry for the slow reply
Christopher W. Ryan writes:
> Any advice for how to get *both* theindex.html and my main document in
> html? So far I can only get one or the other, depending on whether I
> include a non-nil value for a :makeindex option.
I don't understand the question. With the option `:makeindex t' a
document `theindex.inc' is created/updated every time you call
`org-publish-project', and also a document `theindex.org', which
contains the directive `#+INCLUDE: theindex.inc'. This is the document
which is exported to html as an index, along with the rest of the org
documents that you have inside the folder specified in the
`:base-directory' option.
For more info, you can evaluate (info (org) Generating an index)
What is your org-publish configuration?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Export Org mode files to (gag, barf) MS Office?
@ 2021-06-26 15:15 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-26 15:15 UTC (permalink / raw)
To: Brandon Taylor; +Cc: orgmode
Hello,
Brandon Taylor writes:
> I know we’re not supposed to really even TALK about proprietary
> software in FOSS communities like this one, but I can’t help but
> wonder if someone might consider making (an) Emacs plugin(s) that
> allow(s) a user to export Org mode files to Microsoft Office file
> formats such as .docx, .xlsx and the like? Or is/are there already (a)
> plugin(s) in the MELPA that can do this?
You may be interested in the variable `org-odt-preferred-output-format'.
According to the docstring:
"[...] Automatically post-process to this format after exporting to
"odt". Command ‘org-odt-export-to-odt’ exports first to "odt" format and
then uses ‘org-odt-convert-process’ to convert the resulting document to
this format. During customization of this variable, the list of valid
values are populated based on ‘org-odt-convert-capabilities’.[...]"
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Virtually prefix headlines according to content
@ 2021-06-29 13:34 10% ` Juan Manuel Macías
2021-06-29 13:53 5% ` John Kitchin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-29 13:34 UTC (permalink / raw)
To: Rodrigo Morales; +Cc: orgmode
Rodrigo Morales writes:
> What I would like to know is whether it is possible to format a headline
> by taking into consideration the properties it has. For example, in this
> specific scenario, I would like to make all headlines that have a
> "GITHUB" to show "GH" before the actual headline (the content would look
> like this).
You can define a function with `org-map-entries' that adds (for example) a
tag :github: to all headers with the property GITHUB:
#+begin_src emacs-lisp
(defun add-github-tag ()
(interactive)
(org-map-entries (lambda ()
(save-restriction
(save-excursion
(org-narrow-to-subtree)
(goto-char (point-min))
(end-of-line)
(insert " :github:"))))
"+GITHUB={.+}"))
(add-hook 'org-mode-hook #'add-github-tag)
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Virtually prefix headlines according to content
2021-06-29 13:34 10% ` Juan Manuel Macías
@ 2021-06-29 13:53 5% ` John Kitchin
2021-06-29 20:44 0% ` Samuel Wales
0 siblings, 1 reply; 200+ results
From: John Kitchin @ 2021-06-29 13:53 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Rodrigo Morales
[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]
you could use this alternative to just change the display without adding
the tag:
(org-map-entries (lambda ()
(looking-at org-heading-regexp)
(put-text-property (match-beginning 2) (match-end 2) 'display (concat "GH
" (match-string 2))))
"+GITHUB={.+}")
There might be some clever way to tie that onto fontlock, or some kind of
hook to make it also work for entries as you create them.
John
-----------------------------------
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
On Tue, Jun 29, 2021 at 9:35 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Rodrigo Morales writes:
>
> > What I would like to know is whether it is possible to format a headline
> > by taking into consideration the properties it has. For example, in this
> > specific scenario, I would like to make all headlines that have a
> > "GITHUB" to show "GH" before the actual headline (the content would look
> > like this).
>
> You can define a function with `org-map-entries' that adds (for example) a
> tag :github: to all headers with the property GITHUB:
>
> #+begin_src emacs-lisp
> (defun add-github-tag ()
> (interactive)
> (org-map-entries (lambda ()
> (save-restriction
> (save-excursion
> (org-narrow-to-subtree)
> (goto-char (point-min))
> (end-of-line)
> (insert " :github:"))))
> "+GITHUB={.+}"))
>
> (add-hook 'org-mode-hook #'add-github-tag)
> #+end_src
>
> Best regards,
>
> Juan Manuel
>
>
>
[-- Attachment #2: Type: text/html, Size: 2679 bytes --]
^ permalink raw reply [relevance 5%]
* Re: Virtually prefix headlines according to content
2021-06-29 13:53 5% ` John Kitchin
@ 2021-06-29 20:44 0% ` Samuel Wales
0 siblings, 0 replies; 200+ results
From: Samuel Wales @ 2021-06-29 20:44 UTC (permalink / raw)
To: John Kitchin; +Cc: Juan Manuel Macías, Rodrigo Morales, orgmode
along similar lines one possibility is to stick a symbol into the
stars. similar code could also indicate that scheduled and deadline.
On 6/29/21, John Kitchin <jkitchin@andrew.cmu.edu> wrote:
> you could use this alternative to just change the display without adding
> the tag:
>
> (org-map-entries (lambda ()
> (looking-at org-heading-regexp)
> (put-text-property (match-beginning 2) (match-end 2) 'display (concat "GH
> " (match-string 2))))
> "+GITHUB={.+}")
>
> There might be some clever way to tie that onto fontlock, or some kind of
> hook to make it also work for entries as you create them.
> John
>
> -----------------------------------
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
>
> On Tue, Jun 29, 2021 at 9:35 AM Juan Manuel Macías <maciaschain@posteo.net>
> wrote:
>
>> Rodrigo Morales writes:
>>
>> > What I would like to know is whether it is possible to format a
>> > headline
>> > by taking into consideration the properties it has. For example, in
>> > this
>> > specific scenario, I would like to make all headlines that have a
>> > "GITHUB" to show "GH" before the actual headline (the content would
>> > look
>> > like this).
>>
>> You can define a function with `org-map-entries' that adds (for example)
>> a
>> tag :github: to all headers with the property GITHUB:
>>
>> #+begin_src emacs-lisp
>> (defun add-github-tag ()
>> (interactive)
>> (org-map-entries (lambda ()
>> (save-restriction
>> (save-excursion
>> (org-narrow-to-subtree)
>> (goto-char (point-min))
>> (end-of-line)
>> (insert " :github:"))))
>> "+GITHUB={.+}"))
>>
>> (add-hook 'org-mode-hook #'add-github-tag)
>> #+end_src
>>
>> Best regards,
>>
>> Juan Manuel
>>
>>
>>
>
--
The Kafka Pandemic
Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
^ permalink raw reply [relevance 0%]
* Re: convert subtree or nested list to table
@ 2021-07-05 20:01 10% ` Juan Manuel Macías
[not found] ` <CAN_Dec8iqKS+3qvjkYvQxovegnEzqR_rra0Q-ZA9baPz1mXDAA@mail.gmail.com>
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-05 20:01 UTC (permalink / raw)
To: Matt Price; +Cc: orgmode
Hi Matt,
Matt Price writes:
> I have to write a number of text-heavy documents which need to be
> delivered as tables with wrapped paragraphs in most cells. Working
> directly in table format is pretty arduous and uncomfortable. Has
> anyone ever written a function to accept a list or subtree as input
> and process it into a table?
>
> If anyone has done something similar, I'd love some tips!
Some time ago I wrote some functions for my personal use that allow edit
table cells (with a lot of text and/or paragraphs) in a dedicated
buffer. I don't know if something like that is what you are looking for,
but if you are interested, I can clean up the code a bit and upload it
here.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: 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
2021-07-07 6:18 0% ` Uwe Brauer
2021-07-07 21:16 6% ` Matt Price
0 siblings, 2 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: convert subtree or nested list to table
2021-07-06 12:56 8% ` Juan Manuel Macías
@ 2021-07-07 6:18 0% ` Uwe Brauer
2021-07-07 18:27 10% ` Juan Manuel Macías
2021-07-07 21:16 6% ` Matt Price
1 sibling, 1 reply; 200+ results
From: Uwe Brauer @ 2021-07-07 6:18 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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.
Sorry for jumping into that thread. I could not resist downloading your
code and trying it out.
> - As for the code, there are two basic functions:
> `my-org/edit-table-cell' and
that worked.
> `my-org/kill-edit-table-cell-buffer-and-save'. To edit an empty cell,
> you have to write something in that cell first.
When I changed the text in a cell and called that function I obtained
and error
,----
|
| Debugger entered--Lisp error: (wrong-number-of-arguments #f(compiled-function (arg) (interactive "*P") #<bytecode 0x8df3ba5756afab4>) 2)
| fill-paragraph(nil t)
| (let ((fill-column (point-max)) (emacs-lisp-docstring-fill-column t)) (fill-paragraph nil region))
| unfill-paragraph(t)
| funcall-interactively(unfill-paragraph t)
| call-interactively(unfill-paragraph)
| my-org/kill-edit-table-cell-buffer-and-save()
| funcall-interactively(my-org/kill-edit-table-cell-buffer-and-save)
| call-interactively(my-org/kill-edit-table-cell-buffer-and-save record nil)
| command-execute(my-org/kill-edit-table-cell-buffer-and-save record)
| execute-extended-command(nil "my-org/kill-edit-table-cell-buffer-and-save" "my-org/k")
| funcall-interactively(execute-extended-command nil "my-org/kill-edit-table-cell-buffer-and-save" "my-org/k")
| call-interactively(execute-extended-command nil nil)
| command-execute(execute-extended-command)
|
`----
I am running (a couple of week old) GNU emacs master and org-mode git
master. I even restarted my emacs session
What do I miss?
Regards
Uwe Brauer
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: convert subtree or nested list to table
2021-07-07 6:18 0% ` Uwe Brauer
@ 2021-07-07 18:27 10% ` Juan Manuel Macías
2021-07-07 18:44 0% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-07 18:27 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe, thanks for testing the code.
Uwe Brauer writes:
> I am running (a couple of week old) GNU emacs master and org-mode git
> master. I even restarted my emacs session
>
> What do I miss?
I can't reproduce the issue (GNU Emacs 27.2 and org git master). In my
case everything works as expected (taking into account that with this
code of mine the expectations have to be modest :-).
I will do a test on Emacs master...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: convert subtree or nested list to table
2021-07-07 18:27 10% ` Juan Manuel Macías
@ 2021-07-07 18:44 0% ` Uwe Brauer
0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2021-07-07 18:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Uwe, thanks for testing the code.
> Uwe Brauer writes:
>> I am running (a couple of week old) GNU emacs master and org-mode git
>> master. I even restarted my emacs session
>>
>> What do I miss?
> I can't reproduce the issue (GNU Emacs 27.2 and org git master). In my
> case everything works as expected (taking into account that with this
> code of mine the expectations have to be modest :-).
Could also be some of my pkg file. I might check it
starting emacs -q
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: convert subtree or nested list to table
2021-07-06 12:56 8% ` Juan Manuel Macías
2021-07-07 6:18 0% ` Uwe Brauer
@ 2021-07-07 21:16 6% ` Matt Price
1 sibling, 0 replies; 200+ results
From: Matt Price @ 2021-07-07 21:16 UTC (permalink / raw)
To: Juan Manuel Macías, Org Mode
[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]
thank you Juan Mnauel. I'm testing it out, but I do wonder if I would
really rather work with lists and some CSS!
On Tue, Jul 6, 2021 at 8:56 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> 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: Type: text/html, Size: 1901 bytes --]
^ permalink raw reply [relevance 6%]
* [PATCH] [BUG] Bad fontification in full displayed links
@ 2021-07-09 9:15 10% Juan Manuel Macías
2021-07-10 1:50 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-09 9:15 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 178 bytes --]
Hi,
To reproduce the bug:
1. Put some link: [[target][description]]
2. Run `org-toggle-link-display'
As a possible fix I'm attaching this patch.
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 10%]
* Re: [PATCH] [BUG] Bad fontification in full displayed links
2021-07-09 9:15 10% [PATCH] [BUG] Bad fontification in full displayed links Juan Manuel Macías
@ 2021-07-10 1:50 6% ` Ihor Radchenko
2021-07-10 12:12 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-07-10 1:50 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> As a possible fix I'm attaching this patch.
> + (add-face-text-property start visible-start face-property)
> + (add-face-text-property visible-start visible-end face-property)
> + (add-face-text-property visible-end end face-property)
Why not just (add-face-text-property start end face-property)?
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: [PATCH] [BUG] Bad fontification in full displayed links
2021-07-10 1:50 6% ` Ihor Radchenko
@ 2021-07-10 12:12 10% ` Juan Manuel Macías
2021-07-27 20:02 6% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-10 12:12 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 286 bytes --]
Hi Ihor,
Ihor Radchenko writes:
> Why not just (add-face-text-property start end face-property)?
You are right, I think that solution is much simpler. I attach a
new patch and I have included your name in the commit message, for the
suggestion. Thanks!
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org.el-prevent-partial-fontification-when-a-link-is-.patch --]
[-- Type: text/x-patch, Size: 1114 bytes --]
From 0e31ba4ce76e436712285b163b8595b0a973da94 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 10 Jul 2021 13:53:44 +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: `(add-face-text-property start end face-property)' suggestion
from Ihor Radchenko
---
lisp/org.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index ffcc5945d..eca12a5e7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5228,7 +5228,7 @@ This includes angle, plain, and bracket links."
'org-link))
properties)))
(add-text-properties start visible-start hidden)
- (add-face-text-property visible-start visible-end face-property)
+ (add-face-text-property start end face-property)
(add-text-properties visible-start visible-end properties)
(add-text-properties visible-end end hidden)
(org-rear-nonsticky-at visible-start)
--
2.32.0
^ permalink raw reply related [relevance 10%]
* Re: org-mode export to (latex) PDF
@ 2021-07-10 13:52 10% ` Juan Manuel Macías
2021-07-10 14:13 2% ` Jean-Christophe Helary
2021-07-10 16:13 6% ` Maxim Nikulin
1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-10 13:52 UTC (permalink / raw)
To: Jean-Christophe Helary; +Cc: orgmode
Hi Jean-Christophe,
Jean-Christophe Helary writes:
> I guess it is an issue with the Latex backend and could have been solved with the proper Latex settings, but it seems weird that the default settings do not allow for out-of-the-box multilingual support.
I agree with you that Org should have multilingual support. A few months
ago I started this thread here, with some proposals:
https://orgmode.org/list/87o8d95pvo.fsf@posteo.net/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: org-mode export to (latex) PDF
2021-07-10 13:52 10% ` Juan Manuel Macías
@ 2021-07-10 14:13 2% ` Jean-Christophe Helary
2021-07-10 14:38 8% ` Juan Manuel Macías
2021-07-10 16:13 6% ` Maxim Nikulin
1 sibling, 1 reply; 200+ results
From: Jean-Christophe Helary @ 2021-07-10 14:13 UTC (permalink / raw)
To: orgmode
> On Jul 10, 2021, at 22:52, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Hi Jean-Christophe,
>
> Jean-Christophe Helary writes:
>
>> I guess it is an issue with the Latex backend and could have been solved with the proper Latex settings, but it seems weird that the default settings do not allow for out-of-the-box multilingual support.
>
> I agree with you that Org should have multilingual support. A few months
> ago I started this thread here, with some proposals:
> https://orgmode.org/list/87o8d95pvo.fsf@posteo.net/
Juan,
That's a very interesting proposal. Thank you for the reference.
I had given up on Latex because mixing languages sounded like a huge pain in the butt but I see that without some org-level infrastructure it is not possible to achieve much when exporting to Latex/PDF (unless I missed something).
So I guess I'll just keep my current workflow for now, with ODT as my "pivot" format.
Thank you again, Juan.
--
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/
^ permalink raw reply [relevance 2%]
* Re: org-mode export to (latex) PDF
2021-07-10 14:13 2% ` Jean-Christophe Helary
@ 2021-07-10 14:38 8% ` Juan Manuel Macías
2021-07-10 14:59 4% ` Tim Cross
2021-07-10 15:01 1% ` Jean-Christophe Helary
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-10 14:38 UTC (permalink / raw)
To: Jean-Christophe Helary; +Cc: orgmode
Hi Jean-Christophe,
Jean-Christophe Helary writes:
> I had given up on Latex because mixing languages sounded like a huge
> pain in the butt but I see that without some org-level infrastructure
> it is not possible to achieve much when exporting to Latex/PDF (unless
> I missed something).
Well, LaTeX has excellent (typographic and orthotypographic)
multilingual support, using the babel or polyglossia packages. I
especially recommend babel:
http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf
And LaTeX also has very good support for oriental languages or languages
with complex writing, especially in LuaTeX. In LuaTeX and XeTeX you can
also use opentype fonts and opentype features.
The problem is how to translate that from Org --in an org-centric way--
to LaTeX. Currently, you can apply LaTeX commands for multilingual
management directly in your Org document. For example:
#+LaTeX_Header: \usepackage[several langs]{babel}
@@latex:\begin{otherlanguage*}{german}@@
... some text in german ...
@@latex:\end{otherlanguage*}@@
Recently, I submitted a patch here that allows adding LaTeX attributes
to `quote' blocks. Then, you could do something like this:
#+LaTeX_Header:\usepackage[german,english]{babel}
#+LaTeX_Header:\usepackage{quoting}
#+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
#+LaTeX_Header:\SetBlockEnvironment{quoting}
#+ATTR_LaTeX: :environment foreigndisplayquote :options {german}
#+begin_quote
Eine Erklärung, wie sie einer Schrift in einer Vorrede nach der
Gewohnheit vorausgeschickt wird ---über den Zweck, den der Verfasser
sich in ihr vorgesetzt, sowie über die Veranlassungen und das
Verhältnis, worin er sie zu andern frühern oder gleichzeitigen
Behandlungen desselben Gegenstandes zu stehen glaubt--- scheint bei
einer philosophischen Schrift nicht nur überflüssig, sondern um der
Natur der Sache willen sogar unpassend und zweckwidrig zu sein (Hegel).
#+end_quote
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: org-mode export to (latex) PDF
2021-07-10 14:38 8% ` Juan Manuel Macías
2021-07-10 14:59 4% ` Tim Cross
@ 2021-07-10 15:01 1% ` Jean-Christophe Helary
1 sibling, 0 replies; 200+ results
From: Jean-Christophe Helary @ 2021-07-10 15:01 UTC (permalink / raw)
To: orgmode
> On Jul 10, 2021, at 23:38, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Hi Jean-Christophe,
>
> Jean-Christophe Helary writes:
>
>> I had given up on Latex because mixing languages sounded like a huge
>> pain in the butt but I see that without some org-level infrastructure
>> it is not possible to achieve much when exporting to Latex/PDF (unless
>> I missed something).
>
> Well, LaTeX has excellent (typographic and orthotypographic)
> multilingual support, using the babel or polyglossia packages. I
> especially recommend babel:
> http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf
Thank you very much Juan.
I understand that Latex has excellent support for multilingual files. I use it sometimes for very complex multilingual texts (ancient Japanese and French for ex).
But with UTF-8 being ubiquitous on computers nowadays, I really can't be bothered to have to type all those sequences to have org-mode properly export to PDF something that it exports perfectly well to ODT without requiring anything extra.
Which is the reason why I was wondering about a "generic" default setting where the conversion engine behind org could just use a default multilingual package and a default "wide enough" generic font. I really mean a "good enough" export where all the characters are visible, nothing fancy.
Jean-Christophe
>
> And LaTeX also has very good support for oriental languages or languages
> with complex writing, especially in LuaTeX. In LuaTeX and XeTeX you can
> also use opentype fonts and opentype features.
>
> The problem is how to translate that from Org --in an org-centric way--
> to LaTeX. Currently, you can apply LaTeX commands for multilingual
> management directly in your Org document. For example:
>
> #+LaTeX_Header: \usepackage[several langs]{babel}
>
> @@latex:\begin{otherlanguage*}{german}@@
>
> ... some text in german ...
>
> @@latex:\end{otherlanguage*}@@
>
> Recently, I submitted a patch here that allows adding LaTeX attributes
> to `quote' blocks. Then, you could do something like this:
>
> #+LaTeX_Header:\usepackage[german,english]{babel}
> #+LaTeX_Header:\usepackage{quoting}
> #+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
> #+LaTeX_Header:\SetBlockEnvironment{quoting}
>
> #+ATTR_LaTeX: :environment foreigndisplayquote :options {german}
> #+begin_quote
> Eine Erklärung, wie sie einer Schrift in einer Vorrede nach der
> Gewohnheit vorausgeschickt wird ---über den Zweck, den der Verfasser
> sich in ihr vorgesetzt, sowie über die Veranlassungen und das
> Verhältnis, worin er sie zu andern frühern oder gleichzeitigen
> Behandlungen desselben Gegenstandes zu stehen glaubt--- scheint bei
> einer philosophischen Schrift nicht nur überflüssig, sondern um der
> Natur der Sache willen sogar unpassend und zweckwidrig zu sein (Hegel).
> #+end_quote
>
> Best regards,
>
> Juan Manuel
>
--
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/
^ permalink raw reply [relevance 1%]
* Re: org-mode export to (latex) PDF
2021-07-10 14:38 8% ` Juan Manuel Macías
@ 2021-07-10 14:59 4% ` Tim Cross
2021-07-10 17:40 8% ` Juan Manuel Macías
2021-07-10 15:01 1% ` Jean-Christophe Helary
1 sibling, 1 reply; 200+ results
From: Tim Cross @ 2021-07-10 14:59 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Jean-Christophe,
>
> Jean-Christophe Helary writes:
>
>> I had given up on Latex because mixing languages sounded like a huge
>> pain in the butt but I see that without some org-level infrastructure
>> it is not possible to achieve much when exporting to Latex/PDF (unless
>> I missed something).
>
> Well, LaTeX has excellent (typographic and orthotypographic)
> multilingual support, using the babel or polyglossia packages. I
> especially recommend babel:
> http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf
>
> And LaTeX also has very good support for oriental languages or languages
> with complex writing, especially in LuaTeX. In LuaTeX and XeTeX you can
> also use opentype fonts and opentype features.
>
> The problem is how to translate that from Org --in an org-centric way--
> to LaTeX. Currently, you can apply LaTeX commands for multilingual
> management directly in your Org document. For example:
>
> #+LaTeX_Header: \usepackage[several langs]{babel}
>
> @@latex:\begin{otherlanguage*}{german}@@
>
> ... some text in german ...
>
> @@latex:\end{otherlanguage*}@@
>
> Recently, I submitted a patch here that allows adding LaTeX attributes
> to `quote' blocks. Then, you could do something like this:
>
> #+LaTeX_Header:\usepackage[german,english]{babel}
> #+LaTeX_Header:\usepackage{quoting}
> #+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
> #+LaTeX_Header:\SetBlockEnvironment{quoting}
Just FYI for those who don't know, you can use the org-latex-classes
variable to define your own pseudo document classes, possibly using the
DEFAULT_PACKAGES, PACKAGES, EXTRA_PACKAGES macros and other latex
settings. So for example, you can add the babel or other packages you
want and either make that the 'default' class or specify which class you
want with the #+LATEX_CLASS header. I use this quite a bit because then
I don't have to remember which LATEX_HEADER lines to include in the
document, the specific option settings etc. I don't need support for
multilingual documents, but I do have a number of 'special' documents
(such as one with colours, logos and specific fonts for an employer to
match their 'style guide'. I also have ones for generating project
documents, letters, meeting minutes etc. They all use various different
Latex extensions (particularly ones which don't mix well and cannot be
included with other packages).
The LATEX_HEADER: options are useful for 'one off' documents, but become
a real pain to include all the time. however, I see this quite a lot and
just wanted to highlight that when you need to customise the latex
process, you do have these other options which can be very useful and I
suspect would be good for things like setting up support for
multilingual environments. I also use luatex rather than the default
plain 'latex' (mainly because of better/more flexible font support).
I could be wrong as I've not looked at this in a long time, but one of
the problems with multilingual support in Latex was that it was somewhat
'fragile'. There were a number of packages which did not work well when
combined with certain fonts required for multilingual support and (from
memory) issues with hyphenation and packages which extended some
environments. While it was generally possible to tweak things to get
them to work, it was somewhat challenging to get them to work 'across
the board'. I don't know if this is still the case as it has been some
years incde I've needed to dig into Latex (mainly because now I do
almost everything just in org mode and don't need to!). This, combined
with a smaller user base for multilingual documents, may partly explain
the difficulty in gaining traction in this area. I do recall that
getting a stable general latex environment working for org exports was
somewhat challenging originally.
^ permalink raw reply [relevance 4%]
* Re: org-mode export to (latex) PDF
2021-07-10 13:52 10% ` Juan Manuel Macías
2021-07-10 14:13 2% ` Jean-Christophe Helary
@ 2021-07-10 16:13 6% ` Maxim Nikulin
1 sibling, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-07-10 16:13 UTC (permalink / raw)
To: emacs-orgmode
On 10/07/2021 20:52, Juan Manuel Macías wrote:
>
> I agree with you that Org should have multilingual support. A few months
> ago I started this thread here, with some proposals:
> https://orgmode.org/list/87o8d95pvo.fsf@posteo.net/
I tried to draw more attention to support of locale-aware formatting of
numbers on emacs-devel mail list. Certainly a question concerning
mixed-language buffers were raised. Result of attempts to discuss text
properties to mark regions having alternative languages was just "Which
property will help here? we don't have such properties" from Eli Zaretskii.
> > Jean-Christophe Helary writes:
>
>> I guess it is an issue with the Latex backend and could have been
>> solved with the proper Latex settings, but it seems weird that the
>> default settings do not allow for out-of-the-box multilingual
>> support.
(add-to-list 'org-latex-inputenc-alist '("utf8" . "utf8x"))
might help. I am not an active LaTeX user last years, so I am unaware
whether \usepackage[utf8x]{inputenc} has any drawbacks.
^ permalink raw reply [relevance 6%]
* Re: org-mode export to (latex) PDF
2021-07-10 14:59 4% ` Tim Cross
@ 2021-07-10 17:40 8% ` Juan Manuel Macías
2021-07-12 3:09 4% ` Tim Cross
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-10 17:40 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross writes:
> Just FYI for those who don't know, you can use the org-latex-classes
> variable to define your own pseudo document classes, possibly using the
> DEFAULT_PACKAGES, PACKAGES, EXTRA_PACKAGES macros and other latex
> settings. So for example, you can add the babel or other packages you
> want and either make that the 'default' class or specify which class you
> want with the #+LATEX_CLASS header. I use this quite a bit because then
> I don't have to remember which LATEX_HEADER lines to include in the
> document, the specific option settings etc. I don't need support for
> multilingual documents, but I do have a number of 'special' documents
> (such as one with colours, logos and specific fonts for an employer to
> match their 'style guide'. I also have ones for generating project
> documents, letters, meeting minutes etc. They all use various different
> Latex extensions (particularly ones which don't mix well and cannot be
> included with other packages).
I agree. `Org-latex-classes' is a very good option for create LaTeX
templates, and I have a few classes defined as well. The problem is when
you need really long and complex preambles (it is not a problem that
most users may have, though). In a recent project (a book) my preamble
had about 2000 lines (including macros and environments defined by me,
some functions in Lua for LuaTeX, etc.). With long or complex preambles
it's a bit awkward to do it in Elisp and org-latex-classes. In that
case, I usually write the preamble to an Org document and generate a
*.tex file using org-babel-tangle. Then I include that file at the very
beginning of my document with an \input macro. On the LaTeX side, there
is also the option to create your own sty file:
https://tex.stackexchange.com/questions/77/how-to-make-a-standard-preamble-into-a-package
As an alternative to #+LaTeX_Header you can also include the
preamble in the Org document itself using a LaTeX block:
#+NAME: preamble
#+begin_src latex :exports none
... a lot of latex code
#+end_src
and then, in another block with the keyword `:noweb':
#+begin_src latex :noweb yes :results raw
,#+LaTeX_Header: <<preamble>>
#+end_src
(This useful trick came from Charles Berry in this thread:
https://orgmode.org/list/225A3D45-0F47-4FFE-8BBA-F023CB8C9A6C@health.ucsd.edu/#r)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* 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-mode export to (latex) PDF
2021-07-10 17:40 8% ` Juan Manuel Macías
@ 2021-07-12 3:09 4% ` Tim Cross
0 siblings, 0 replies; 200+ results
From: Tim Cross @ 2021-07-12 3:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Tim Cross writes:
>
>> Just FYI for those who don't know, you can use the org-latex-classes
>> variable to define your own pseudo document classes, possibly using the
>> DEFAULT_PACKAGES, PACKAGES, EXTRA_PACKAGES macros and other latex
>> settings. So for example, you can add the babel or other packages you
>> want and either make that the 'default' class or specify which class you
>> want with the #+LATEX_CLASS header. I use this quite a bit because then
>> I don't have to remember which LATEX_HEADER lines to include in the
>> document, the specific option settings etc. I don't need support for
>> multilingual documents, but I do have a number of 'special' documents
>> (such as one with colours, logos and specific fonts for an employer to
>> match their 'style guide'. I also have ones for generating project
>> documents, letters, meeting minutes etc. They all use various different
>> Latex extensions (particularly ones which don't mix well and cannot be
>> included with other packages).
>
> I agree. `Org-latex-classes' is a very good option for create LaTeX
> templates, and I have a few classes defined as well. The problem is when
> you need really long and complex preambles (it is not a problem that
> most users may have, though). In a recent project (a book) my preamble
> had about 2000 lines (including macros and environments defined by me,
> some functions in Lua for LuaTeX, etc.). With long or complex preambles
> it's a bit awkward to do it in Elisp and org-latex-classes. In that
> case, I usually write the preamble to an Org document and generate a
> *.tex file using org-babel-tangle. Then I include that file at the very
> beginning of my document with an \input macro. On the LaTeX side, there
> is also the option to create your own sty file:
> https://tex.stackexchange.com/questions/77/how-to-make-a-standard-preamble-into-a-package
>
> As an alternative to #+LaTeX_Header you can also include the
> preamble in the Org document itself using a LaTeX block:
>
> #+NAME: preamble
> #+begin_src latex :exports none
>
> ... a lot of latex code
> #+end_src
>
> and then, in another block with the keyword `:noweb':
>
> #+begin_src latex :noweb yes :results raw
> ,#+LaTeX_Header: <<preamble>>
> #+end_src
>
> (This useful trick came from Charles Berry in this thread:
> https://orgmode.org/list/225A3D45-0F47-4FFE-8BBA-F023CB8C9A6C@health.ucsd.edu/#r)
>
Yes, I do pretty much the same. I have a number of personal *.sty files
which contain a lot of additional setup information which would be
difficult to include directly in org-latex-classes.
I have also used the idea of latex blocks and tangling, especially when
working out the details for a specific latex configuration. Once I have
it working, unless this is strictly a 'one off', I will typically move
that information into a *.sty file or similar. I also use a couple of
templates via either company or yasnipet which I use for some org
documents which have a 'standard' outline and header setup.
I find the combination of these techniques makes it easy to create new
documents and maintain existing ones. I have a terrible memory for the
low level configuration stuff, so the more I can rely on pre-defined
configurations, the better. The nice thing about how I have things setup
now is that it seems pretty robust. I rarely encounter any problems when
updating org and am able to get 'up and running' on a new system fairly
quickly. The biggest challenge I've had lately has been my move from my
own standard configuration to using spacemacs. It has taken a bit of
work to get spacemacs to work the way I want, but I have grown to love
the modal editing of evil mode (probably because VI was my first
editor). I'm now very happy with my configuration and workflow.
--
Tim Cross
^ permalink raw reply [relevance 4%]
* 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: org-mode export to (latex) PDF
@ 2021-07-14 17:30 3% ` Maxim Nikulin
2021-07-14 19:29 9% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Maxim Nikulin @ 2021-07-14 17:30 UTC (permalink / raw)
To: emacs-orgmode
On 14/07/2021 13:44, Stefan Nobis wrote:
>
> The main point: utf8x and the associated package ucs are not
> maintained for quite some time (utf8x seems to be last changed in
> 2004) and as far as I understand have always been more of a workaround
> than a solution. But I'm not an expert in this regard.
>
> Nowadays the LaTeX kernel and input encodings like (plain) utf8 are
> much more powerful and extensible and do play much better with other
> packages.
I was unlucky to notice the utf8x option when ≠ character was discussed
on this mail list in the context of pseudocode listings. I am afraid,
year 2004 is impressive in other sense than you expected. "Better"
solution still unable to handle ≠ (unlike deprecated one). Actually
necessity to explicitly specify several fonts reminds me end of previous
century when Cyrillic fonts was not in default package set and required
manual adjustment of config files (not to mention missed support in
babel and inputenc, so several partially incompatible variants were used
at that time).
> You need to specify all fonts that you want to use and that deviate
> from the default (Latin Modern in the case of lualatex). How else
> should the system now that you want something else?
There are cm-super fonts for at least of 15 years. OK, they are Type1,
not otf or ttf and conversion from metafont was not lossless. (Actually
the only real problem I noticed is that some rare printers ignore
hairlines.) Why is the Latin Modern family used if CMU is available?
Nowadays most of applications have no problem with wide range of Unicode
characters. However it is a kind of trade-off to preserve traditional
Computer Modern font (a kind of feature of TeX) or to pick a system font
with more characters.
> The package "unicode-math" should always be used with lualatex and
> xelatex, in order to support unicode math input.
Thank you for the hint. Do you think Org should use it by default? Are
there any caveats?
> In your minimal example neither polyglossia nor babel are required
They are almost unavoidable in any real document unless it is preview of
e.g. particular equation.
On 14/07/2021 00:53, Juan Manuel Macías wrote:> And here I add that
feature to Linux Libertine font:
>
> \setmainfont{Linux Libertine O}[RawFeature=+mysub]
It is wonderful that custom font can be chosen so easily. I was never
brave enough and I did not have strong enough reason to follow lengthy
guides how to use ttf font in latex+dvips+ps2pdf workflow. However
custom fonts are for special documents. 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. I
prefer to do fine tuning at the last stages of preparation of a
document. It is sad that default fonts are often unusable for me.
> For multilingual management I recommend using Babel instead of
> Polyglossia.
I have no experience with polyglossia yet. I added it just because most
of examples for LuaLaTeX or XeLaTeX use it.
TeX takes responsibility for a lot of things and it allows to get rather
pleasant results with minimal efforts due to reasonable defaults. Unlike
Apache FO processor for general formatting. Equations were looking
disgusting in MS Word till ~2010.
This topic started from question concerning multilingual support out of
the box. I can not help with Japanese quotes. However some problems can
be noticed with e.g. (sorry for some raw LaTeX):
---- >8 ----
Test¹ of superscript and ½ fraction.
*«Теорема».* /Пусть/ $α → ∞$ и $\beta \to \infty$.
=Катет= и \textsf{гипотенуза}.
Åå. Text Greek α. µm.
Text utf8x ≠ utf8 and math $8 ≠ x$.
---- 8< -----
Current default in Org is pdflatex. It requires at least adjusting of
fontspec by adding T2A option.
If LuaTeX and XeLaTeX handles Unicode better, is it possible to make any
of them the default option and to leave pdflatex as a fallback? Is it
possible to detect lualatex and xelatex in runtime? I have noticed that
/usr/bin/lualatex belongs to texlive-latex-base package. Originally I
did not have texlive-luatex package installed, so likely lualatex was
rather broken despite presence of the binary in the system.
Should some packages for lualatex and xelatex be added to default list
to minimize user problems and at the same time keeping configuration
safe? (unicode-math, etc.)
Is it possible to provide reasonable defaults for fonts? Since lmodern
is hardcoded in luatex and xetex, it may be done either by some usually
available latex package or by org code and custom variables.
If some defaults can not be determined (e.g. \setmainfont) likely they
should be explicitly mentioned in the org manual.
^ permalink raw reply [relevance 3%]
* Re: org-mode export to (latex) PDF
2021-07-14 17:30 3% ` Maxim Nikulin
@ 2021-07-14 19:29 9% ` Juan Manuel Macías
1 sibling, 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: org-mode export to (latex) PDF
@ 2021-07-15 12:06 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-15 12:06 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross writes:
> Stefan Nobis <stefan-ml@snobis.de> writes:
>> But maybe we could assemble a list of good (enough) fonts for
>> different languages/scripts and provide a default setup in Org for
>> LaTeX export, that sets a proper font for the chosen document
>> language?
> I think such a list would be a really good addition to worg.
I think it's a great idea. Some resources on fonts and languages that
may be useful:
- The LaTeX Font Catalogue (https://tug.org/FontCatalogue/) is pretty
complete and includes a lot of high quality fonts, with coverage for
many languages. The fonts are from diverse origins, for example the
excellent fonts for Greek and Latin alphabets from the Greek Font
Society, the TeX Gyre project fonts, etc.
- To get quick information from an otf font (otf features, Unicode
ranges, scripts, glyphs, etc.) otfinfo is very useful
(https://man.archlinux.org/man/otfinfo.1.en). But the more powerful
tool in this regard is fontforge (https://fontforge.org/en-US/), which
is not only a complete professional font editor (and free as in
freedom) but can also be used by everyone to audit all aspects from a
font: glyphs, metadata, otf features, languages, scripts, ranges, etc.
- There are specialized fonts in a wide coverage of ranges and scripts,
but many are low-quality or proprietary. Google's Noto Fonts ensure at
least a reasonably complete coverage: I use them only for experiments
(or for ensure certain "rare" scripts in Emacs buffers, as Linear B or
Gothic), but they can also be used within a document.
- Finally, in case anyone is interested, I also wrote for my personal
use a Helm source to list all system font families and insert the
family name into a LaTeX document with the syntax of fontspec or Babel
("\babelfont", which is a frontend for fontspec).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: org-mode export to (latex) PDF
@ 2021-07-15 19:40 9% ` Juan Manuel Macías
2021-07-16 16:56 5% ` Maxim Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-15 19:40 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Maxim Nikulin writes:
> In CSS it is possible to specify a list of fonts and a glyph is taken
> from the first font where it is present. Despite particular fonts have
> limited coverage, I see wide range of Unicode characters on web pages,
> that is why I am almost sure that system font libraries combine fonts.
In LuaTeX you can associate a font family to a range or a group of
characters. In a book I typesetted some time ago I used the Cardo font
to represent the characters for Private Use Area.
\newfontfamily\cardo{Cardo} % a fontspec command
\def\puatext#1{{\cardo #1}}
\begin{luacode*}
function my_pua (text)
texto = unicode.utf8.gsub ( text, "([\u{e000}-\u{f8ff}])", "\\puatext{%1}" )
return text
end
\end{luacode*}
\newcommand\activatepuatext{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , my_pua , "my_pua" )}}
\AtBeginDocument{\activatepuatext}
(I add a simple substitution to the callback `process_imput_buffer'
[see: http://wiki.luatex.org/index.php/Callbacks], but these kinds of
overrides can also be do from Org using a custom filter).
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-mode export to (latex) PDF
2021-07-15 19:40 9% ` Juan Manuel Macías
@ 2021-07-16 16:56 5% ` Maxim Nikulin
2021-07-16 18:34 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-07-16 16:56 UTC (permalink / raw)
To: emacs-orgmode
On 16/07/2021 02:40, Juan Manuel Macías wrote:
> Maxim Nikulin writes:
>
>> In CSS it is possible to specify a list of fonts and a glyph is taken
>> from the first font where it is present. Despite particular fonts have
>> limited coverage, I see wide range of Unicode characters on web pages,
>> that is why I am almost sure that system font libraries combine fonts.
>
> In LuaTeX you can associate a font family to a range or a group of
> characters.
>
> texto = unicode.utf8.gsub ( text, "([\u{e000}-\u{f8ff}])", "\\puatext{%1}" )
I expect it is terribly inefficient for long spans of text in particular
language. Command should not be per-character, preferably per-paragraph
or at least per-word
"([\u{e000}-\u{f8ff}]+)"
However maybe you just do not use sequences of symbols from private use
area.
I think that low level implementation in browser or in some underlying
library is much faster
<dl>
<dt>LM Roman 12</dt>
<dd style="font-family: 'LM Roman 12'">abc абв…с</dd>
<dt>LM Roman 12, CMU Serif</dt>
<dd style="font-family: 'LM Roman 12', 'CMU Serif'">abc абв…с</dd>
</dl>
^ permalink raw reply [relevance 5%]
* Re: org-mode export to (latex) PDF
2021-07-16 16:56 5% ` Maxim Nikulin
@ 2021-07-16 18:34 7% ` Juan Manuel Macías
2021-07-17 12:35 4% ` Maxim Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-16 18:34 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Maxim Nikulin writes:
> I think that low level implementation in browser or in some underlying
> library is much faster
>
> <dl>
> <dt>LM Roman 12</dt>
> <dd style="font-family: 'LM Roman 12'">abc абв…с</dd>
> <dt>LM Roman 12, CMU Serif</dt>
> <dd style="font-family: 'LM Roman 12', 'CMU Serif'">abc абв…с</dd>
> </dl>
They are two different scenarios: web publishing and book typesetting
(Donald Knuth in the TexBook refers to TeX as: "...a new typesetting
system intended for the creation of beautiful books [...] you will be
telling a computer exactly how the manuscript is to be transformed into
pages whose typographic quality is comparable to that of the world's
finest printers"). LuaTeX, like the rest of TeX engines, is a highly
refined typesetting system, the digital evolution of the mechanical
printing press and the art of typographers. Its goal is printing press
instead of web browsers. All decisions regarding the chosen typefaces
should be taken before. When I prepare a book design, all those
decisions I take them before, and it takes time to test and calibrate
typefaces: choose the font family, or font family groups for certain
languages. Mixing fonts is not trivial for professional typography. This
is not the scenario you describe, nor is it necessary to ensure
readability in multiple browsers with "fallback fonts" for missed
glyphs. In TeX ecosystem it makes no sense (it can be done, anyway[1])
to add fallback fonts to ensure all characters are rendered by their
corresponding glyphs. I insist: they are two orthogonal scenarios and
two diametrically opposed design concepts.
If the font I want to use lacks certain glyphs, I can take various
decisions, depending on the glyphs I need. If I lack only certain
diacritics, often with some Lua code it is enough for me (some Lua is
also usually useful to adjust the position of combining diacritical
marks without editing the font with fontforge and add a 'mark' or
'marktomark' tag). But, generally, if a font doesn't have the glyphs I
need, I just don't use it. The same is true in the case of small caps.
If a font does not have small caps, you should never use those horrible
and illegible synthesized small caps from DTP programs ...
In LuaTeX and XeTeX you can define at high level, for example, your own
hybrid font families. If I want to use the GFS Porson as italics from
another font, a Didot typeface for example, I can do this:
\newfontfamily\mygreek{GFS Didot Classic}
[Script=Greek,ItalicFont=GFS Porson,ItalicFeatures={Scale=.90}]
\emfontdeclare{\itshape,\upshape}
\mygreek
γίγνονται παῖδες δύο, \emph{πρεσβύτερος} μὲν Ἀρταξέρξης
[1] If you want to have fallback fonts, you can also do it in
LuaTeX by adding some Lua code:
https://tex.stackexchange.com/questions/514940/define-fallback-font-for-missing-glyphs-in-lualatex
(anyway, I insist that combining glyphs is something you must
be done with care)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: org-mode export to (latex) PDF
2021-07-16 18:34 7% ` Juan Manuel Macías
@ 2021-07-17 12:35 4% ` Maxim Nikulin
2021-07-17 14:27 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-07-17 12:35 UTC (permalink / raw)
To: emacs-orgmode
On 17/07/2021 01:34, Juan Manuel Macías wrote:
> Maxim Nikulin writes:
>
>> I think that low level implementation in browser or in some underlying
>> library is much faster
>>
>> <dl>
>> <dt>LM Roman 12</dt>
>> <dd style="font-family: 'LM Roman 12'">abc абв…с</dd>
>> <dt>LM Roman 12, CMU Serif</dt>
>> <dd style="font-family: 'LM Roman 12', 'CMU Serif'">abc абв…с</dd>
>> </dl>
>
> They are two different scenarios: web publishing and book typesetting
Juan Manuel, it seems you are too inclined to book typesetting. It is
important case and it should be supported by org. I have repeated two
times in this thread that there is another case, namely routine quick
notes. Such documents have another balance concerning time required to
get acceptable result. TeX takes responsibility for a lot of defaults
such as what spaces should be added around "=" and what ones around
right angle bracket. Users do not need to make decisions concerning such
design details to get accurately typeset equations.
At the age of custom charsets (often 8bit) and encodings the problem of
multilingual texts was obvious. Unicode and UTF-8 alleviate many issues.
It happened that Cyrillic is an edge case for Unicode TeX engines. Since
~2000 it works out of the box for LaTeX and PdfLaTeX. Last years I did
not need to adjust config files and regenerate formats. Hyphenation,
default fonts (OK, "apt install cm-super" to avoid rasterized fonts is a
bit behind defaults though no manual config is required) just work. Each
document needs a few universal lines to setup Russian. Some users may
have specific style files but generally source documents are quite portable.
Default fonts for LuaTeX and XeTeX do not include Cyrillic any more.
Every user have to do a decision which fonts should be used even if one
does not care concerning particular fonts. It increases probability to
get a file with font configuration that is specific to Mac or Windows.
I do not actively use characters from other Unicode planes, however
sometimes I do it for fun. Getting them completely missing is less
preferred than displaying them with low quality font. Specifying all
fonts requires lengthy config, probably different for LuaTeX and XeTeX.
At first it is necessary to realize which fonts are available for
particular glyph. Finally it makes *source* document less portable.
"font-family: 'LM Roman 12', 'CMU Serif'" above is a dumb example of
what I consider relatively high-level config for routine documents that
do not need to be handcrafted. Unavailable glyph or even font is not an
error, it just causes lookup of candidates in the following items. For
TeX maybe it is reasonable to consider fallback to complete set of fonts
at ones (roman + mono + math) if such combination is available.
> If I want to use the GFS Porson as italics from
> another font, a Didot typeface for example, I can do this:
If it is not a book or at the stage of early draft another scenario is
possible. Text should just appear in the compiled document, particular
font does not matter, its choice is postponed since text content has
higher priority. Minimal setup in invaluable.
At least with minimal examples I faced another issue: characters
silently disappears, no warning is generated. Adding babel changes it,
but I still believe that especially for documents with carefully chosen
fonts. It is a serious hidden error to get "invalid char glyph" instead
of all missed characters.
> [1] If you want to have fallback fonts, you can also do it in
> LuaTeX by adding some Lua code:
> https://tex.stackexchange.com/questions/514940/define-fallback-font-for-missing-glyphs-in-lualatex
Would you recommend such code as default for Org? Let's assume that some
information concerning system fonts are available. I suspect, the
accepted answer is not fool-proof. In addition, XeLaTeX requires
something different.
luaotfload provides fallback feature close to what I expect, however it
is necessary to explicitly specify script that I would prefer to avoid.
Moreover it significantly increases compilation time. Sometimes LuaLaTeX
starts to eat CPU with no progress, emoji does not work for some reason.
I am unsure concerning particular "Noto Sans CJK" since several ones are
available.
\documentclass{article}
\usepackage{fontspec}
\usepackage{unicode-math}
\directlua{luaotfload.add_fallback
("seriffallback",
{
"Noto Serif CJK SC:mode=harf;script=sc;",
"file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
})
}
% TwemojiMozilla is not shown by viewers, visible in pdftotext
%"Noto Color Emoji:mode=harf;"
% or
%"file:/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf:mode=harf;"
% </usr/share/fonts/truetype/noto/NotoColorEmoji.ttf
% ! error: (file /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf)
(ttf): loca
% table not found
% ! ==> Fatal error occurred, no output PDF file produced!
\setmainfont{CMU Serif}[RawFeature={fallback=seriffallback}]
\directlua{luaotfload.add_fallback
("sansfallback",
{
"Noto Sans CJK SC:mode=harf;script=sc;",
"file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
})
}
\setsansfont{CMU Sans Serif}[RawFeature={fallback=sansfallback}]
\directlua{luaotfload.add_fallback
("monofallback",
{
"Noto Sans Mono CJK SC:mode=harf;script=sc;",
"file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
})
}
\setmonofont{CMU Typewriter Text}[RawFeature={fallback=monofallback}]
\begin{document}
Test¹ of superscript and ½ fraction.
\textbf{«Теорема».} \emph{Пусть} $α → ∞$ и $\beta \to \infty$.
\verb=Катет= и \textsf{гипотенуза}.
Åå. Text Greek α.
Text utf8x ≠ utf8 and math $utf8x ≠ utf8$.
Randomly chosen examples: "日本", "多喝水", "📞".
\verb=Randomly chosen examples: "日本", "多喝水", "📞".=
\end{document}
^ permalink raw reply [relevance 4%]
* Re: org-mode export to (latex) PDF
2021-07-17 12:35 4% ` Maxim Nikulin
@ 2021-07-17 14:27 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-17 14:27 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim,
I think the problem is not the fact that I may be inclined towards book
typesetting but that TeX itself and its workflow is inclined towards
book typesetting. This fact is something that must be taken into account
and that many LaTeX users sometimes forget. The concept of a 'fallback
font' is still something exotic for the TeX working method, despite that
LuaTeX can access TeX primitives using scripting in lua and can achieve
things like that, at the cost of resources. For example, the fontspec
package provides the conditional \IfFontExists{font}{True code}{False
code} which consumes a lot of resources.
Anyway, I would dare to recommend these two possibilities:
a) If you want to define a list of fallback fonts for the LaTeX
process, IMHO should be done org-centric with Elisp (something for
pdfTeX, XeTeX and LuaTeX. I'm afraid this would be a lot of work and too
much cholesterol for Org Mode, though).
b) However, my preference is something that has already been comented in
this thread: add to the documentation (or to Worg web site) a (not too
long) list of recommended fonts for different languages: of course,
fonts that are freely licensed and accessible to everyone. In any
collaborative work in LaTeX I find it's much more simple to share an
easily accessible and free (as in freedom) font than to add a list of
fallback fonts to the documents via code (a true bloat for TeX). The
LaTeX Font Catalogue includes lots of very good quality fonts. For
example, TeX Live includes an excellent font with support for Greek,
Cyrillic and Linguistics: Old Standard, originally designed by prof.
Alexey Kryukov and currently maintained by Robert Alessi:
https://www.ctan.org/pkg/oldstandard (I don't work on Cyrillic and I can
not comment on that aspect: I use this font more for Greek; but it is
often said that Old Standard is one of the best and most documented
options to represent Cyrillic).
Best regards,
Juan Manuel
Maxim Nikulin writes:
> On 17/07/2021 01:34, Juan Manuel Macías wrote:
>> Maxim Nikulin writes:
>>
>>> I think that low level implementation in browser or in some underlying
>>> library is much faster
>>>
>>> <dl>
>>> <dt>LM Roman 12</dt>
>>> <dd style="font-family: 'LM Roman 12'">abc абв…с</dd>
>>> <dt>LM Roman 12, CMU Serif</dt>
>>> <dd style="font-family: 'LM Roman 12', 'CMU Serif'">abc абв…с</dd>
>>> </dl>
>> They are two different scenarios: web publishing and book
>> typesetting
>
> Juan Manuel, it seems you are too inclined to book typesetting. It is
> important case and it should be supported by org. I have repeated two
> times in this thread that there is another case, namely routine quick
> notes. Such documents have another balance concerning time required to
> get acceptable result. TeX takes responsibility for a lot of defaults
> such as what spaces should be added around "=" and what ones around
> right angle bracket. Users do not need to make decisions concerning
> such design details to get accurately typeset equations.
>
> At the age of custom charsets (often 8bit) and encodings the problem
> of multilingual texts was obvious. Unicode and UTF-8 alleviate many
> issues. It happened that Cyrillic is an edge case for Unicode TeX
> engines. Since ~2000 it works out of the box for LaTeX and PdfLaTeX.
> Last years I did not need to adjust config files and regenerate
> formats. Hyphenation, default fonts (OK, "apt install cm-super" to
> avoid rasterized fonts is a bit behind defaults though no manual
> config is required) just work. Each document needs a few universal
> lines to setup Russian. Some users may have specific style files but
> generally source documents are quite portable.
>
> Default fonts for LuaTeX and XeTeX do not include Cyrillic any more.
> Every user have to do a decision which fonts should be used even if
> one does not care concerning particular fonts. It increases
> probability to get a file with font configuration that is specific to
> Mac or Windows.
>
> I do not actively use characters from other Unicode planes, however
> sometimes I do it for fun. Getting them completely missing is less
> preferred than displaying them with low quality font. Specifying all
> fonts requires lengthy config, probably different for LuaTeX and
> XeTeX. At first it is necessary to realize which fonts are available
> for particular glyph. Finally it makes *source* document less
> portable.
>
> "font-family: 'LM Roman 12', 'CMU Serif'" above is a dumb example of
> what I consider relatively high-level config for routine documents
> that do not need to be handcrafted. Unavailable glyph or even font is
> not an error, it just causes lookup of candidates in the following
> items. For TeX maybe it is reasonable to consider fallback to complete
> set of fonts at ones (roman + mono + math) if such combination is
> available.
>
>> If I want to use the GFS Porson as italics from
>> another font, a Didot typeface for example, I can do this:
>
> If it is not a book or at the stage of early draft another scenario is
> possible. Text should just appear in the compiled document, particular
> font does not matter, its choice is postponed since text content has
> higher priority. Minimal setup in invaluable.
>
> At least with minimal examples I faced another issue: characters
> silently disappears, no warning is generated. Adding babel changes it,
> but I still believe that especially for documents with carefully
> chosen fonts. It is a serious hidden error to get "invalid char glyph"
> instead of all missed characters.
>
>> [1] If you want to have fallback fonts, you can also do it in
>> LuaTeX by adding some Lua code:
>> https://tex.stackexchange.com/questions/514940/define-fallback-font-for-missing-glyphs-in-lualatex
>
> Would you recommend such code as default for Org? Let's assume that
> some information concerning system fonts are available. I suspect, the
> accepted answer is not fool-proof. In addition, XeLaTeX requires
> something different.
>
> luaotfload provides fallback feature close to what I expect, however
> it is necessary to explicitly specify script that I would prefer to
> avoid. Moreover it significantly increases compilation time. Sometimes
> LuaLaTeX starts to eat CPU with no progress, emoji does not work for
> some reason.
> I am unsure concerning particular "Noto Sans CJK" since several ones
> are available.
>
> \documentclass{article}
> \usepackage{fontspec}
> \usepackage{unicode-math}
> \directlua{luaotfload.add_fallback
> ("seriffallback",
> {
> "Noto Serif CJK SC:mode=harf;script=sc;",
> "file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
> })
> }
> % TwemojiMozilla is not shown by viewers, visible in pdftotext
> %"Noto Color Emoji:mode=harf;"
> % or
> %"file:/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf:mode=harf;"
> % </usr/share/fonts/truetype/noto/NotoColorEmoji.ttf
> % ! error: (file /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf)
> (ttf): loca
> % table not found
> % ! ==> Fatal error occurred, no output PDF file produced!
> \setmainfont{CMU Serif}[RawFeature={fallback=seriffallback}]
>
> \directlua{luaotfload.add_fallback
> ("sansfallback",
> {
> "Noto Sans CJK SC:mode=harf;script=sc;",
> "file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
> })
> }
> \setsansfont{CMU Sans Serif}[RawFeature={fallback=sansfallback}]
>
> \directlua{luaotfload.add_fallback
> ("monofallback",
> {
> "Noto Sans Mono CJK SC:mode=harf;script=sc;",
> "file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
> })
> }
> \setmonofont{CMU Typewriter Text}[RawFeature={fallback=monofallback}]
> \begin{document}
> Test¹ of superscript and ½ fraction.
>
> \textbf{«Теорема».} \emph{Пусть} $α → ∞$ и $\beta \to \infty$.
>
> \verb=Катет= и \textsf{гипотенуза}.
>
> Åå. Text Greek α.
>
> Text utf8x ≠ utf8 and math $utf8x ≠ utf8$.
>
> Randomly chosen examples: "日本", "多喝水", "📞".
>
> \verb=Randomly chosen examples: "日本", "多喝水", "📞".=
> \end{document}
>
>
^ permalink raw reply [relevance 7%]
* Multilingual quotes inside paragraphs
@ 2021-07-26 9:25 7% Juan Manuel Macías
2021-07-28 12:13 5% ` Maxim Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-26 9:25 UTC (permalink / raw)
To: orgmode
Hi all,
I'm experimenting with `org-link-set-parameters' to create multilingual
quotes (chunks of text) inside paragraphs. Although I focus mainly on
the export to LaTeX with babel and csquotes packages, I also want extend
support for HTML and odt output. I leave here some sketches.
For the `:face' parameter I use for laziness a face already defined in
Magit :-). `:display' with the value 'full can be removed.
First, we have the LaTeX babel command \foreignlanguage{lang}{chunk of
text}. The language can be expressed by abbreviation ("de" for German;
here I reuse `org-latex-babel-language-alist') or explicitly preceded by
a "!": "!german" (the reason for the latter is that in babel we can
define new languages):
[[lang:de][some text in German]]
or
[[lang:!german][some text in German]]
The code:
(org-link-set-parameters "lang"
:display 'full
:face 'magit-header-line-key
:export (lambda (target desc format)
(cond
((eq format 'latex)
(let ((langs org-latex-babel-language-alist))
(concat
"\\foreignlanguage{"
(if (string-match-p "!" target)
(replace-regexp-in-string "!" "" target)
(cdr (assoc target langs)))
"}{" desc "}")))
;; TODO
((or (eq format 'html)
(eq format 'odt))
(format "%s" desc)))))
We also have this command from the csquotes package for foreign quoted
texts (loads only the hyphenation rules for the language and sets the
text between quotation marks): \hyphentextquote{lang}{quoted text}. For
this I have defined a new link "qlang":
(org-link-set-parameters "qlang"
:display 'full
:face 'magit-header-line-key
:export (lambda (target desc format)
(cond
((eq format 'latex)
(let ((langs org-latex-babel-language-alist))
(concat
"\\hyphentextquote{"
(if (string-match-p "!" target)
(replace-regexp-in-string "!" "" target)
(cdr (assoc target langs)))
"}{" desc "}")))
((or (eq format 'html)
(eq format 'odt))
;; TODO (use here the proper quotes)
(format "«%s»" desc)))))
We can even make the citations come out in color when we are in draft
mode, thanks to the LaTeX ifdraft package:
(org-link-set-parameters "qlang"
:display 'full
:face 'magit-header-line-key
:export (lambda (target desc format)
(cond
((eq format 'latex)
(let ((langs org-latex-babel-language-alist))
(concat
"{\\ifdraft{\\color{teal}}{}\\hyphentextquote{"
(if (string-match-p "!" target)
(replace-regexp-in-string "!" "" target)
(cdr (assoc target langs)))
"}{"
desc "}}")))
((or (eq format 'html)
(eq format 'odt))
;; TODO
(format "«%s»" desc)))))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: [PATCH] [BUG] Bad fontification in full displayed links
2021-07-10 12:12 10% ` Juan Manuel Macías
@ 2021-07-27 20:02 6% ` Nicolas Goaziou
0 siblings, 0 replies; 200+ results
From: Nicolas Goaziou @ 2021-07-27 20:02 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Ihor Radchenko
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> You are right, I think that solution is much simpler. I attach a
> new patch and I have included your name in the commit message, for the
> suggestion. Thanks!
Applied. Thank you.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* Re: Multilingual quotes inside paragraphs
2021-07-26 9:25 7% Multilingual quotes inside paragraphs Juan Manuel Macías
@ 2021-07-28 12:13 5% ` Maxim Nikulin
2021-07-28 13:49 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-07-28 12:13 UTC (permalink / raw)
To: emacs-orgmode
On 26/07/2021 16:25, Juan Manuel Macías wrote:
>
> I'm experimenting with `org-link-set-parameters' to create multilingual
> quotes (chunks of text) inside paragraphs. Although I focus mainly on
> the export to LaTeX with babel and csquotes packages, I also want extend
> support for HTML and odt output. I leave here some sketches.
Are you intentionally avoiding macros {{{lang(ru, текст)}}}? It seems,
you are abusing links a bit. Though it allows to hide "target" part and
thus to reduce "noise" in the text. On the other hand, links may be
broadly considered as customizable element ("interactive" property is
not necessary for such snippets) since there are no other similar
objects in Org syntax. One problem is support in 3rd party tools:
pandoc, various renderers, e.g. (ruby?) on github.
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. A workaround is possible:
lang:de?href=https%3A%2F%2Forgmode.org%2F with some code for handling of
unescaped target. I expect complains that it is not user-friendly to
require splitting fragment at the borders of inner link. Org does not
support nested objects of the same type.
> or explicitly preceded by
> a "!": "!german" (the reason for the latter is that in babel we can
> define new languages):
Unsure that ODT and HTML allows to define languages. I would consider
some lisp structures describing mapping of customizable languages codes
to some set of properties.
^ permalink raw reply [relevance 5%]
* Re: Multilingual quotes inside paragraphs
2021-07-28 12:13 5% ` Maxim Nikulin
@ 2021-07-28 13:49 8% ` Juan Manuel Macías
2021-08-01 16:02 5% ` Maxim Nikulin
0 siblings, 1 reply; 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%]
* Re: Multilingual quotes inside paragraphs
2021-07-28 13:49 8% ` Juan Manuel Macías
@ 2021-08-01 16:02 5% ` Maxim Nikulin
0 siblings, 0 replies; 200+ results
From: Maxim Nikulin @ 2021-08-01 16:02 UTC (permalink / raw)
To: emacs-orgmode
On 28/07/2021 20:49, Juan Manuel Macías wrote:
> 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?
My personal impression is that lightweight Org markup is suitable for
simple documents. Problems grow as a snowball as soon as a document
becomes more complex. If syntax were extended too much, Org would loose
its simplicity that is one of its advantage. Complex documents require
more strict and flexible thus more verbose markup format.
It seems, your have tried all possible variants for inline quotes
https://orgmode.org/worg/dev/org-syntax.html#Objects
macros, src_org{}, even links and nothing is perfect
https://orgmode.org/list/875yzwce28.fsf@posteo.net
Code for any approach may be polished to some extent, but some
limitations will remain.
^ permalink raw reply [relevance 5%]
* Re: TMIO July Post: Introducing Citations
@ 2021-08-02 7:23 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-02 7:23 UTC (permalink / raw)
To: Timothy; +Cc: orgmode
Hi Timothy,
Timothy writes:
> Hi Everyone,
>
> Just letting you know that on my blog TMIO (This Month In Org) I've just
> published the July post. I've decided to focus entirely on citations
> this time :)
>
> Should this be of interest, here it is:
> https://blog.tecosaur.com/tmio/2021-07-31-citations.html
Thank you very much for this comprehensive and very useful post: the
best way to start my summer vacation! :-)
And many thanks to those who have developed this interesting and
promising new Org feature.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [PATCH] ox.el: fix spanish translation for `footnotes'
@ 2021-08-03 10:47 10% Juan Manuel Macías
2021-08-07 20:10 6% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-08-03 10:47 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 267 bytes --]
Hi,
The Spanish translation for "Footnotes" in `org-export-dictionary' is
"Nota al pie de página" ("Nota"[="Note"], in the singular form). I think
it would be more correct "Notas", in the plural form. Attached a small
patch.
Best regards,
Juan Manuel
[-- Attachment #2: 0001-ox.el-fix-spanish-translation-for-footnotes.patch --]
[-- Type: text/x-patch, Size: 1063 bytes --]
From 4109c6f2bc38d56b0a67c482afc3feeddfcf3084 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 3 Aug 2021 12:31:02 +0200
Subject: [PATCH] ox.el: fix spanish translation for `footnotes'
* lisp/ox.el (org-export-dictionary): tiny fix in spanish translation (plural instead of singular)
---
lisp/ox.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index 16b87a7ed..418c680b0 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5928,7 +5928,7 @@ them."
("da" :default "Fodnoter")
("de" :html "Fußnoten" :default "Fußnoten")
("eo" :default "Piednotoj")
- ("es" :ascii "Nota al pie de pagina" :html "Nota al pie de página" :default "Nota al pie de página")
+ ("es" :ascii "Notas al pie de pagina" :html "Notas al pie de página" :default "Notas al pie de página")
("et" :html "Allmärkused" :utf-8 "Allmärkused")
("fi" :default "Alaviitteet")
("fr" :default "Notes de bas de page")
--
2.32.0
^ permalink raw reply related [relevance 10%]
* Re: ConTeXt exporter for Org Mode
@ 2021-08-04 19:43 10% ` Juan Manuel Macías
2021-08-05 10:23 6% ` András Simonyi
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-08-04 19:43 UTC (permalink / raw)
To: Jason Ross; +Cc: orgmode
Hi Jason,
Jason Ross writes:
> Hello,
>
> I have developed a ConTeXt exporter for Org Mode. It is available at
> https://github.com/Jason-S-Ross/ox-context
>
> The exporter provides custom environments for each document element
> in an effort to make customization easier, in contrast to the Pandoc
> exporter which uses built-in environments for document elements.
>
> I welcome any feedback.
Congratulations on your excellent work. I am not a daily ConTeXt user, and I'm
afraid I can't help much. But I think a native exporter to ConTeXt
could be an important addition to Org. It could be interesting for users
who want to discover this powerful alternative to LaTeX (within the TeX
ecosystem), as well as for users who want high-quality pdf output without
the need for get caught up in the complexity of LaTeX packages, since
ConTeXt has a more monolithic conception than LaTeX.
Very interesting and promising, in any case.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: ConTeXt exporter for Org Mode
2021-08-04 19:43 10% ` Juan Manuel Macías
@ 2021-08-05 10:23 6% ` András Simonyi
0 siblings, 0 replies; 200+ results
From: András Simonyi @ 2021-08-05 10:23 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Jason Ross
Dear Jason,
this is excellent news, thanks for your work! I always wondered why
there is no Org exporter for ConTeXt which seemed such an obvious
target -- can't wait to try it out!
best regards,
András
On Wed, 4 Aug 2021 at 21:44, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Hi Jason,
>
> Jason Ross writes:
>
> > Hello,
> >
> > I have developed a ConTeXt exporter for Org Mode. It is available at
> > https://github.com/Jason-S-Ross/ox-context
> >
> > The exporter provides custom environments for each document element
> > in an effort to make customization easier, in contrast to the Pandoc
> > exporter which uses built-in environments for document elements.
> >
> > I welcome any feedback.
>
> Congratulations on your excellent work. I am not a daily ConTeXt user, and I'm
> afraid I can't help much. But I think a native exporter to ConTeXt
> could be an important addition to Org. It could be interesting for users
> who want to discover this powerful alternative to LaTeX (within the TeX
> ecosystem), as well as for users who want high-quality pdf output without
> the need for get caught up in the complexity of LaTeX packages, since
> ConTeXt has a more monolithic conception than LaTeX.
>
> Very interesting and promising, in any case.
>
> Best regards,
>
> Juan Manuel
>
>
>
^ permalink raw reply [relevance 6%]
* "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: [PATCH] ox.el: fix spanish translation for `footnotes'
2021-08-03 10:47 10% [PATCH] ox.el: fix spanish translation for `footnotes' Juan Manuel Macías
@ 2021-08-07 20:10 6% ` Nicolas Goaziou
0 siblings, 0 replies; 200+ results
From: Nicolas Goaziou @ 2021-08-07 20:10 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The Spanish translation for "Footnotes" in `org-export-dictionary' is
> "Nota al pie de página" ("Nota"[="Note"], in the singular form). I think
> it would be more correct "Notas", in the plural form. Attached a small
> patch.
Applied. Thank you.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* [tip] get the verse number at point inside a verse block
@ 2021-08-13 13:45 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-13 13:45 UTC (permalink / raw)
To: orgmode
Hi,
We're highly unlikely to feel in our life the strange need to know the
verse number at point within a verse block (verse numbers are not equal
to line numbers).
However, in my translation of Homer's Odyssey (work in progress), I
often need to get (at point) both the verse number and the book number,
so that it can be canonically cited in many references I include in the
prologue and footnotes. For example: Od. 2.125 (book + verse). So I
wrote this little code:
First, you get the verse number at point:
#+begin_src emacs-lisp
(defun verse-num-at-point ()
"Return the verse number at point inside a `verse' block"
(save-excursion
(end-of-line)
(save-restriction
(org-narrow-to-block)
(narrow-to-region (point-min) (point))
(goto-char (point-min))
(end-of-line)
(let
((versenum 0))
(save-excursion
(while
(re-search-forward "^." nil t)
(setf versenum (+ versenum 1)))
(setq verse-at-point versenum)))))
verse-at-point)
#+end_src
And, with this function, you get the canonical citation (taking into
account that book number is a property named `:book:'):
#+begin_src emacs-lisp
(defun locate-odyssey ()
(interactive)
(let ((book (org-entry-get nil "book"))
(verse (verse-num-at-point)))
(message "Od. %s.%s" book verse)
(kill-new (format "Od. %s.%s" book verse))))
#+end_src
Bonus track: I also wrote this little package to display verse numbers
at margin: https://gitlab.com/maciaschain/org-verse-num
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: return column from table as a column
@ 2021-08-13 14:47 10% ` Juan Manuel Macías
2021-08-13 16:32 6% ` Roger Mason
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-08-13 14:47 UTC (permalink / raw)
To: Roger Mason; +Cc: orgmode
Hi Roger,
It's a dirty solution, but you can try:
#+name: s1
| scale | scale1 | scale3 | jid |
| - | 1.00402 | 0.952329 | 1632 |
| - | 1.00402 | 0.962247 | 1633 |
#+begin_src emacs-lisp :var data=s1 col=3
(let* ((column (mapcar (lambda (r) (format "%s" (nth col r))) data)))
(mapcar 'list column))
#+end_src
#+RESULTS:
| jid |
| 1632 |
| 1633 |
Best regards,
Juan Manuel
Roger Mason writes:
> Hello,
>
> I need to extract a column from a table to use as input to a source
> block. I want the extracted column to be returned as a column but it is
> returned as a row. The following illustrates the problem:
>
> #+name: s1
> | scale | scale1 | scale3 | jid |
>
> | - | 1.00402 | 0.952329 | 1632 |
> | - | 1.00402 | 0.962247 | 1633 |
>
> #+begin_src emacs-lisp :var data=s1[,3]
> data
> #+end_src
>
> #+RESULTS:
> | jid | 1632 | 1633 |
>
> I want:
>
> | jid |
> | 1632 |
> | 1633 |
>
> Is there some means of changing 'data=s1[,3]' to accomplish this?
>
> Thanks,
> Roger
>
> GNU Emacs 27.2 (build 1, amd64-portbld-freebsd11.4, X toolkit, cairo
> version 1.16.0, Xaw3d scroll bars)
>
> Org mode version 9.2.3 (release_9.2.3-390-gfb5091 @
> /home/rmason/.emacs.d/org-git/lisp/)
>
^ permalink raw reply [relevance 10%]
* Re: return column from table as a column
2021-08-13 14:47 10% ` Juan Manuel Macías
@ 2021-08-13 16:32 6% ` Roger Mason
2021-08-13 17:12 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Roger Mason @ 2021-08-13 16:32 UTC (permalink / raw)
To: orgmode
Hello Juan,
Juan Manuel Macías writes:
> #+name: s1
> | scale | scale1 | scale3 | jid |
> | - | 1.00402 | 0.952329 | 1632 |
> | - | 1.00402 | 0.962247 | 1633 |
>
> #+begin_src emacs-lisp :var data=s1 col=3
> (let* ((column (mapcar (lambda (r) (format "%s" (nth col r))) data)))
> (mapcar 'list column))
> #+end_src
>
> #+RESULTS:
> | jid |
> | 1632 |
> | 1633 |
Thank you, I think I may be able to get this to work.
Roger
^ permalink raw reply [relevance 6%]
* Re: return column from table as a column
2021-08-13 16:32 6% ` Roger Mason
@ 2021-08-13 17:12 10% ` Juan Manuel Macías
2021-08-14 10:30 6% ` Roger Mason
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-08-13 17:12 UTC (permalink / raw)
To: Roger Mason; +Cc: orgmode
Hello Roger,
Roger Mason writes:
> Thank you, I think I may be able to get this to work.
You're welcome. Just a minor fix: although the code works fine,
naturally the asterisk in `let' was unnecessary. This is a new version
with the code explained, in case you find it useful:
#+begin_src emacs-lisp :var data=s1 col=3
(let* (
;; return a list from elemens in column number `col'
(list-from-column (mapcar (lambda (r) (format "%s" (nth col r))) data))
;; make a list of lists = a new table that contains one single column
(new-table (mapcar 'list list-from-column)))
new-table)
#+end_src
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Org + git branches for derived files
@ 2021-08-13 20:53 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-13 20:53 UTC (permalink / raw)
To: Ken Mankoff; +Cc: orgmode
Hi Ken,
Ken Mankoff writes:
> I'd like to keep derivative products (the LaTeX output, the final PDF,
> etc.) available in Git, but not commit those changes each time I
> change the Org file. Perhaps git-annex as appropriate for this, but
> seems over-kill.
>
> Is there some way to mostly-seamlessly commit the LaTeX and/or PDF
> and/or other files to their own git branches but in a way that
> overwrites the history of that branch, so that a small Org file that
> generates a big binary PDF does not pollute the git tree?
There are probably better solutions, but maybe this could help you:
use org-publish (which also works when the output is LaTeX/PDF, and
not only with HTML). See https://orgmode.org/manual/Publishing.html
You should have to define a new publishing project and declare a
directory for the PDFs derivatives, applying a value to
:publishing-directory, and configure in this directory a second git
repository, only for PDFs. The value of :publishing-function keyword
should be `org-latex-publish-to-pdf'.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Custom function for killing the thing at point
@ 2021-08-13 22:46 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-13 22:46 UTC (permalink / raw)
To: Rodrigo Morales; +Cc: orgmode
Hi Rodrigo,
Thanks for sharing, it seems interesting and useful. But I think this
function is missing in your post: `my/kill-new'.
Best regards,
Juan Manuel
Rodrigo Morales writes:
> I just created this function for copying the thing under the cursor (it
> works for some #+BEGIN blocks and links). I think it would be useful for
> others, so I'm creating this post for getting feedback on the Elisp code
> and sharing it to those interested.
>
> #+BEGIN_SRC elisp
> (defun my/org-kill-thing-at-point ()
> "Kill the thing at point.
>
> The following things are currently supported
>
> - #+BEGIN_SRC <<any>>
> - #+BEGIN_EXPORT <<any>>
> - #+BEGIN_EXAMPLE <<any>>
> - #+BEGIN_COMMENT
> - Org links (the description is not copied)"
> (interactive)
> (let* (content
> (element (org-element-context))
> (type (org-element-type element)))
> (cond ((or (eq type 'src-block)
> (eq type 'export-block)
> (eq type 'example-block)
> (eq type 'comment-block))
> (setq content (plist-get (cadr element) :value)))
> ((eq type 'link)
> (setq content (plist-get (cadr element) :raw-link)))
> (t
> (error "The element at point couldn't be copied.")))
> (my/kill-new content)))
> #+END_SRC
>
> #+BEGIN_SRC elisp
> (define-key org-mode-map (kbd "C-c c") 'my/org-kill-thing-at-point)
> #+END_SRC
>
^ permalink raw reply [relevance 10%]
* Re: return column from table as a column
2021-08-13 17:12 10% ` Juan Manuel Macías
@ 2021-08-14 10:30 6% ` Roger Mason
0 siblings, 0 replies; 200+ results
From: Roger Mason @ 2021-08-14 10:30 UTC (permalink / raw)
To: orgmode
Hello Juan,
Juan Manuel Macías writes:
> You're welcome. Just a minor fix: although the code works fine,
> naturally the asterisk in `let' was unnecessary. This is a new version
> with the code explained, in case you find it useful:
>
> #+begin_src emacs-lisp :var data=s1 col=3
> (let* (
> ;; return a list from elemens in column number `col'
> (list-from-column (mapcar (lambda (r) (format "%s" (nth col r))) data))
> ;; make a list of lists = a new table that contains one single column
> (new-table (mapcar 'list list-from-column)))
> new-table)
> #+end_src
Many thanks for this. A looong time ago I was capable of programming in
emacs-lisp. Alas I have not maintained my skills.
Best wishes,
Roger
^ permalink raw reply [relevance 6%]
* Smart quotes for Greek (questions for a possible patch)
@ 2021-08-14 15:06 7% Juan Manuel Macías
2021-08-15 15:59 5% ` Maxim Nikulin
2021-08-15 21:28 6% ` mvar
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-14 15:06 UTC (permalink / raw)
To: orgmode
Hi,
I would like to submit a patch to add smart quotes for Greek in
`org-export-smart-quotes-alist', but I have a couple of questions.
First of all, I am not a native speaker of Greek but of Spanish, so I
would also like to have the opinion of some Greek native speaker, to see
if my solutions are correct.
The second question concerns the second-level quotation marks for Greek.
The first level ones are the same as the Spanish or French quotes
(without the extra space of French): «», so no problem. I follow here
the rule that Yannis Haralambous explains in "From Unicode to
Typography, a Case Study: the Greek Script" (1999, p. 20:
http://web.archive.org/web/20120229131933/http://omega.enstb.org/yannis/pdf/boston99.pdf).
According to Haralambous, on the second-level quotation marks (the
emphases are mine):
#+begin_quote
Also interesting is the case of the second level quotes. Here, quotes of
the size and shape of the English ones are used, but the opening quotes
are inverted, similar in form to raised small round guillemets [...].
Fortunately these quotes are provided by the Unicode standard (*U+201F*
and U+201D, the latter being the same closing double quotes as in
English); *the author knows no other language in which this combination
of double quotes might be used*.
#+end_quote
So the problem is in the character U+201F (assuming Haralambous is
right). For the keywords `:utf8' and `html' no problem. But I don't know
what to put in `:latex' or in `:texinfo':
#+begin_src emacs-lisp
(secondary-opening :utf-8 "‟" :html "‟;" :latex "??" :texinfo "??")
#+end_src
In fact, I think latex2e has no command or shorthand predefined for this
character (see https://ibb.co/ZBGmwYP). There would be no problem with
LuaTeX and XeTeX. But this character would be difficult to obtain in
pdfTeX even using inputenc with the utf8 option.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Smart quotes for Greek (questions for a possible patch)
2021-08-14 15:06 7% Smart quotes for Greek (questions for a possible patch) Juan Manuel Macías
@ 2021-08-15 15:59 5% ` Maxim Nikulin
2021-08-15 21:28 6% ` mvar
1 sibling, 0 replies; 200+ results
From: Maxim Nikulin @ 2021-08-15 15:59 UTC (permalink / raw)
To: emacs-orgmode
On 14/08/2021 22:06, Juan Manuel Macías wrote:
>
> I would like to submit a patch to add smart quotes for Greek in
> `org-export-smart-quotes-alist', but I have a couple of questions.
>
> First of all, I am not a native speaker of Greek
Disclaimer: I am not a Greek speaker at all.
> Yannis Haralambous explains in "From Unicode to
> Typography, a Case Study: the Greek Script" (1999, p. 20:
> http://web.archive.org/web/20120229131933/http://omega.enstb.org/yannis/pdf/boston99.pdf).
>
> Fortunately these quotes are provided by the Unicode standard (*U+201F*
> and U+201D, the latter being the same closing double quotes as in
> English);
There is no Greek page for
https://en.wikipedia.org/wiki/Quotation_mark
As to English page, notice
https://en.wikipedia.org/wiki/Quotation_mark#Summary_table
https://en.wikipedia.org/wiki/Quotation_mark#Greek
sections. It cites
http://publications.europa.eu/code/el/el-4100107el.htm
that uses “ U+0201C (“, &lquo;, or &lquot;) and ” U+0201D (”,
&rquo;, or &rquot;) as inner quotes. If it is acceptable to use this
pair, LaTeX commands likely may be \textquotedblleft and
\textquotedblright (or simply `` and ''). I have not noticed anything
more appropriate in "The Comprehensive LATEX Symbol List". Even
https://www.ctan.org/pkg/babel-greek does not suggest proper way for
inner quotes.
Even if precise variant is uncertain, maybe any reasonable choice is
better than currently used defaults. Anyway it may be corrected later.
> #+begin_src emacs-lisp
> (secondary-opening :utf-8 "‟" :html "‟;" :latex "??" :texinfo "??")
> #+end_src
It seems, there is no named entity for U+0201F
https://html.spec.whatwg.org/multipage/named-characters.html#named-character-references
For some unclear reason (there is a badge requesting references),
Russian page
https://ru.wikipedia.org/wiki/Кавычки
mentions
- «…» as usually used outer,
- ‹…› as usually used inner,
- “…” as alternative outer,
- ‘…’ as alternative inner
quotes. Perhaps, it is just a mistake.
^ permalink raw reply [relevance 5%]
* Re: Smart quotes for Greek (questions for a possible patch)
2021-08-15 21:28 6% ` mvar
@ 2021-08-16 13:57 8% ` Juan Manuel Macías
2021-08-27 16:23 3% ` Protesilaos Stavrou
1 sibling, 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%]
* Search in descriptive plain lists
@ 2021-08-19 11:04 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-19 11:04 UTC (permalink / raw)
To: orgmode
Hi all,
For my translation (work in progress) of Homer's Odyssey I am writing a long descriptive
plain list which is a glossary of Homeric formulas (in Homer a 'formula' is a passage that
is repeated exactly the same, or with slight variations, throughout the work: a very
typical resource of traditional poems). This glossary helps me remember how I have
translated a certain formula before. But it was a bit awkward for me having to query the
list every time so I wrote a function which returns as a message the item searched after
writing or marking a few words. I have redone a bit the code to give it a more general
use, and I share it here, in case someone found useful or perhaps would like to improve
it. The idea is to search in descriptive lists within sections containing the tag :makealist:
(one list per section). And has more sense when the descriptive lists work as a kind of
glossary.
#+begin_src emacs-lisp
(setq my-org/desc-plainlist-alist nil)
(defun my-org/search-desc-plainlist ()
(interactive)
(org-map-entries
(lambda ()
(save-restriction
(org-narrow-to-subtree)
(when
(re-search-forward "^- " nil t)
(beginning-of-line)
(mapc (lambda (el)
(add-to-list 'my-org/desc-plainlist-alist el))
(cdr (org-list-to-lisp))))))
"makealist")
(let ((element-re (if (region-active-p)
(buffer-substring-no-properties (region-beginning) (region-end))
(read-from-minibuffer "Search in descriptive lists: "))))
(setq my-org/desc-plainlist-candidate
(assoc-if
(lambda (x)
(string-match-p element-re x))
my-org/desc-plainlist-alist))
(message
(mapconcat 'identity
my-org/desc-plainlist-candidate ""))))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Smart quotes for Greek (questions for a possible patch)
2021-08-14 15:06 7% Smart quotes for Greek (questions for a possible patch) Juan Manuel Macías
2021-08-15 15:59 5% ` Maxim Nikulin
@ 2021-08-15 21:28 6% ` mvar
2021-08-16 13:57 8% ` Juan Manuel Macías
2021-08-27 16:23 3% ` Protesilaos Stavrou
1 sibling, 2 replies; 200+ results
From: mvar @ 2021-08-15 21:28 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: public, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi,
>
> I would like to submit a patch to add smart quotes for Greek in
> `org-export-smart-quotes-alist', but I have a couple of questions.
>
> First of all, I am not a native speaker of Greek but of Spanish, so I
> would also like to have the opinion of some Greek native speaker, to see
> if my solutions are correct.
>
> The second question concerns the second-level quotation marks for Greek.
> The first level ones are the same as the Spanish or French quotes
> (without the extra space of French): «», so no problem. I follow here
> the rule that Yannis Haralambous explains in "From Unicode to
> Typography, a Case Study: the Greek Script" (1999, p. 20:
> http://web.archive.org/web/20120229131933/http://omega.enstb.org/yannis/pdf/boston99.pdf).
>
> According to Haralambous, on the second-level quotation marks (the
> emphases are mine):
>
> #+begin_quote
>
> Also interesting is the case of the second level quotes. Here, quotes of
> the size and shape of the English ones are used, but the opening quotes
> are inverted, similar in form to raised small round guillemets [...].
> Fortunately these quotes are provided by the Unicode standard (*U+201F*
> and U+201D, the latter being the same closing double quotes as in
> English); *the author knows no other language in which this combination
> of double quotes might be used*.
>
> #+end_quote
>
>
> So the problem is in the character U+201F (assuming Haralambous is
> right). For the keywords `:utf8' and `html' no problem. But I don't know
> what to put in `:latex' or in `:texinfo':
>
> #+begin_src emacs-lisp
> (secondary-opening :utf-8 "‟" :html "‟;" :latex "??" :texinfo "??")
> #+end_src
>
> In fact, I think latex2e has no command or shorthand predefined for this
> character (see https://ibb.co/ZBGmwYP). There would be no problem with
> LuaTeX and XeTeX. But this character would be difficult to obtain in
> pdfTeX even using inputenc with the utf8 option.
>
> Best regards,
>
> Juan Manuel
hi Juan,
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.
cheers,
Michalis
^ permalink raw reply [relevance 6%]
* Re: how to get multi-line author in ODT export?
@ 2021-08-26 16:05 10% ` Juan Manuel Macías
2021-08-26 16:54 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-08-26 16:05 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Hi Eric,
I think the problem is in this two lines of `org-odt-template', that
creates the meta.xml file inside the odt file:
(format "<dc:creator>%s</dc:creator>\n" author)
(format "<meta:initial-creator>%s</meta:initial-creator>\n" author)
Perhaps, modifying them like this:
(format "<dc:creator><![CDATA[%s]]></dc:creator>\n" (replace-regexp-in-string "\\\\\\\\" "\n" author))
(format "<meta:initial-creator><![CDATA[%s]]></meta:initial-creator>\n" (replace-regexp-in-string "\\\\\\\\" "\n" author))
We could do this in our documents:
#+AUTHOR: Han Solo \\ Chewbacca
(little tested)
Best regards,
Juan Manuel
Eric S Fraga writes:
> So, as usual, I answer my own question, sort of.
>
> The problem is that org exports the author text enclosed within a
> special directives, specifically:
>
> (format "<text:initial-creator>%s</text:initial-creator>" author))
>
> New line directives are not allowed within this declaration, it
> seems. Removing (manually) the initial-creator directive then works.
>
> So, my question would be: is this text:initial-creator tagging
> necessary? If not, can we remove it? The OpenDocument schema is vague
> about whether this is necessary. If we cannot remove it, i.e if
> initial-creator is required in the document, could it be put in
> separately (as a meta:initial-creator tag) so that the author field can
> be more general?
>
> I am *not* an ODT expert of any sort. But it is my route to Word
> documents when the need arises (which is luckily seldom).
>
> Anyway, no panic: I can simply manually edit the odt file just before
> the final processing...
>
> Thank you,
> eric
^ permalink raw reply [relevance 10%]
* Re: how to get multi-line author in ODT export?
2021-08-26 16:05 10% ` Juan Manuel Macías
@ 2021-08-26 16:54 13% ` Juan Manuel Macías
2021-08-26 18:34 6% ` John Kitchin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-08-26 16:54 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Hi again,
Another simpler approach, with a filter:
#+TITLE: The kessel run in 12 parsecs
#+AUTHOR: Han Solo !!! Chewbacca !!! Lando Calrissian
#+BIND: org-export-filter-plain-text-functions (author-lb-filter)
#+begin_src emacs-lisp :exports results :results none
(defun author-lb-filter (text backend info)
(cond ((org-export-derived-backend-p backend 'odt)
(replace-regexp-in-string "!!!" "\n" text))
((org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string "!!!" "\\\\\\\\" text))))
#+end_src
Content...
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Hi Eric,
>
> I think the problem is in this two lines of `org-odt-template', that
> creates the meta.xml file inside the odt file:
>
> (format "<dc:creator>%s</dc:creator>\n" author)
> (format "<meta:initial-creator>%s</meta:initial-creator>\n" author)
>
> Perhaps, modifying them like this:
>
> (format "<dc:creator><![CDATA[%s]]></dc:creator>\n" (replace-regexp-in-string "\\\\\\\\" "\n" author))
> (format "<meta:initial-creator><![CDATA[%s]]></meta:initial-creator>\n" (replace-regexp-in-string "\\\\\\\\" "\n" author))
>
> We could do this in our documents:
>
> #+AUTHOR: Han Solo \\ Chewbacca
>
> (little tested)
>
> Best regards,
>
> Juan Manuel
>
> Eric S Fraga writes:
>
>> So, as usual, I answer my own question, sort of.
>>
>> The problem is that org exports the author text enclosed within a
>> special directives, specifically:
>>
>> (format "<text:initial-creator>%s</text:initial-creator>" author))
>>
>> New line directives are not allowed within this declaration, it
>> seems. Removing (manually) the initial-creator directive then works.
>>
>> So, my question would be: is this text:initial-creator tagging
>> necessary? If not, can we remove it? The OpenDocument schema is vague
>> about whether this is necessary. If we cannot remove it, i.e if
>> initial-creator is required in the document, could it be put in
>> separately (as a meta:initial-creator tag) so that the author field can
>> be more general?
>>
>> I am *not* an ODT expert of any sort. But it is my route to Word
>> documents when the need arises (which is luckily seldom).
>>
>> Anyway, no panic: I can simply manually edit the odt file just before
>> the final processing...
>>
>> Thank you,
>> eric
>
>
^ permalink raw reply [relevance 13%]
* Re: how to get multi-line author in ODT export?
2021-08-26 16:54 13% ` Juan Manuel Macías
@ 2021-08-26 18:34 6% ` John Kitchin
2021-08-27 1:46 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: John Kitchin @ 2021-08-26 18:34 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Eric S Fraga
[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]
That is really nice, thanks for sharing it!
John
-----------------------------------
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
On Thu, Aug 26, 2021 at 12:55 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi again,
>
> Another simpler approach, with a filter:
>
> #+TITLE: The kessel run in 12 parsecs
> #+AUTHOR: Han Solo !!! Chewbacca !!! Lando Calrissian
>
> #+BIND: org-export-filter-plain-text-functions (author-lb-filter)
> #+begin_src emacs-lisp :exports results :results none
> (defun author-lb-filter (text backend info)
> (cond ((org-export-derived-backend-p backend 'odt)
> (replace-regexp-in-string "!!!" "\n" text))
> ((org-export-derived-backend-p backend 'latex)
> (replace-regexp-in-string "!!!" "\\\\\\\\" text))))
> #+end_src
>
> Content...
>
> Best regards,
>
> Juan Manuel
>
> Juan Manuel Macías writes:
>
> > Hi Eric,
> >
> > I think the problem is in this two lines of `org-odt-template', that
> > creates the meta.xml file inside the odt file:
> >
> > (format "<dc:creator>%s</dc:creator>\n" author)
> > (format "<meta:initial-creator>%s</meta:initial-creator>\n" author)
> >
> > Perhaps, modifying them like this:
> >
> > (format "<dc:creator><![CDATA[%s]]></dc:creator>\n"
> (replace-regexp-in-string "\\\\\\\\" "\n" author))
> > (format "<meta:initial-creator><![CDATA[%s]]></meta:initial-creator>\n"
> (replace-regexp-in-string "\\\\\\\\" "\n" author))
> >
> > We could do this in our documents:
> >
> > #+AUTHOR: Han Solo \\ Chewbacca
> >
> > (little tested)
> >
> > Best regards,
> >
> > Juan Manuel
> >
> > Eric S Fraga writes:
> >
> >> So, as usual, I answer my own question, sort of.
> >>
> >> The problem is that org exports the author text enclosed within a
> >> special directives, specifically:
> >>
> >> (format "<text:initial-creator>%s</text:initial-creator>" author))
> >>
> >> New line directives are not allowed within this declaration, it
> >> seems. Removing (manually) the initial-creator directive then works.
> >>
> >> So, my question would be: is this text:initial-creator tagging
> >> necessary? If not, can we remove it? The OpenDocument schema is vague
> >> about whether this is necessary. If we cannot remove it, i.e if
> >> initial-creator is required in the document, could it be put in
> >> separately (as a meta:initial-creator tag) so that the author field can
> >> be more general?
> >>
> >> I am *not* an ODT expert of any sort. But it is my route to Word
> >> documents when the need arises (which is luckily seldom).
> >>
> >> Anyway, no panic: I can simply manually edit the odt file just before
> >> the final processing...
> >>
> >> Thank you,
> >> eric
> >
> >
>
>
[-- Attachment #2: Type: text/html, Size: 4111 bytes --]
^ permalink raw reply [relevance 6%]
* Re: how to get multi-line author in ODT export?
2021-08-26 18:34 6% ` John Kitchin
@ 2021-08-27 1:46 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-27 1:46 UTC (permalink / raw)
To: John Kitchin; +Cc: orgmode, Eric S Fraga
Hi John,
you're welcome. I realized that in these lines of the meta.xml file:
<dc:creator> ... </dc:creator>
<meta:initial-creator> ... </meta:initial-creator>
line breaks can be achieved simply by adding a new line without marks (as
discussed in this thread:
https://stackoverflow.com/questions/10917555/adding-a-new-line-break-tag-in-xml/10923392)
Best regards,
Juan Manuel
John Kitchin writes:
> That is really nice, thanks for sharing it!
> John
>
> -----------------------------------
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
> On Thu, Aug 26, 2021 at 12:55 PM Juan Manuel Macías
> <maciaschain@posteo.net> wrote:
>
> Hi again,
>
> Another simpler approach, with a filter:
>
> #+TITLE: The kessel run in 12 parsecs
> #+AUTHOR: Han Solo !!! Chewbacca !!! Lando Calrissian
>
> #+BIND: org-export-filter-plain-text-functions (author-lb-filter)
> #+begin_src emacs-lisp :exports results :results none
> (defun author-lb-filter (text backend info)
> (cond ((org-export-derived-backend-p backend 'odt)
> (replace-regexp-in-string "!!!" "\n" text))
> ((org-export-derived-backend-p backend 'latex)
> (replace-regexp-in-string "!!!" "\\\\\\\\" text))))
> #+end_src
>
> Content...
>
> Best regards,
>
> Juan Manuel
>
> Juan Manuel Macías writes:
>
> > Hi Eric,
> >
> > I think the problem is in this two lines of `org-odt-template',
> that
> > creates the meta.xml file inside the odt file:
> >
> > (format "<dc:creator>%s</dc:creator>\n" author)
> > (format "<meta:initial-creator>%s</meta:initial-creator>\n"
> author)
> >
> > Perhaps, modifying them like this:
> >
> > (format "<dc:creator><![CDATA[%s]]></dc:creator>\n"
> (replace-regexp-in-string "\\\\\\\\" "\n" author))
> > (format "<meta:initial-creator><![CDATA
> [%s]]></meta:initial-creator>\n" (replace-regexp-in-string
> "\\\\\\\\" "\n" author))
> >
> > We could do this in our documents:
> >
> > #+AUTHOR: Han Solo \\ Chewbacca
> >
> > (little tested)
> >
> > Best regards,
> >
> > Juan Manuel
> >
> > Eric S Fraga writes:
> >
> >> So, as usual, I answer my own question, sort of.
> >>
> >> The problem is that org exports the author text enclosed within
> a
> >> special directives, specifically:
> >>
> >> (format "<text:initial-creator>%s</text:initial-creator>"
> author))
> >>
> >> New line directives are not allowed within this declaration, it
> >> seems. Removing (manually) the initial-creator directive then
> works.
> >>
> >> So, my question would be: is this text:initial-creator tagging
> >> necessary? If not, can we remove it? The OpenDocument schema
> is vague
> >> about whether this is necessary. If we cannot remove it, i.e
> if
> >> initial-creator is required in the document, could it be put in
> >> separately (as a meta:initial-creator tag) so that the author
> field can
> >> be more general?
> >>
> >> I am *not* an ODT expert of any sort. But it is my route to
> Word
> >> documents when the need arises (which is luckily seldom).
> >>
> >> Anyway, no panic: I can simply manually edit the odt file just
> before
> >> the final processing...
> >>
> >> Thank you,
> >> eric
> >
> >
>
^ permalink raw reply [relevance 10%]
* Re: pygments support
@ 2021-08-27 13:49 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-27 13:49 UTC (permalink / raw)
To: Yuchen Pei; +Cc: orgmode
Hi Yuchen,
I only know this one, but haven't tried it:
https://github.com/or/pygments-orgmode-lexer
Best regards,
Juan Manuel
Yuchen Pei writes:
> Hello,
>
> I was playing with my cgit setup when I noticed that pygments does not
> support org mode syntax highlighting[1].
>
> Just wondering if anyone has worked on it, or if there's any
> "unofficial" org mode component (lexer?), before I go ahead and
> try to write my own.
>
> [1]: https://pygments.org/languages/
^ permalink raw reply [relevance 10%]
* Re: Smart quotes for Greek (questions for a possible patch)
2021-08-15 21:28 6% ` mvar
2021-08-16 13:57 8% ` Juan Manuel Macías
@ 2021-08-27 16:23 3% ` Protesilaos Stavrou
2021-08-31 11:11 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Protesilaos Stavrou @ 2021-08-27 16:23 UTC (permalink / raw)
To: mvar, Juan Manuel Macías; +Cc: orgmode
On 2021-08-16, 00:28 +0300, mvar <mvar.40k@gmail.com> wrote:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Hi,
>>
>> I would like to submit a patch to add smart quotes for Greek in
>> `org-export-smart-quotes-alist', but I have a couple of questions.
>>
>> First of all, I am not a native speaker of Greek but of Spanish, so I
>> would also like to have the opinion of some Greek native speaker, to see
>> if my solutions are correct.
>>
>> The second question concerns the second-level quotation marks for Greek.
>> The first level ones are the same as the Spanish or French quotes
>> (without the extra space of French): «», so no problem. I follow here
>> the rule that Yannis Haralambous explains in "From Unicode to
>> Typography, a Case Study: the Greek Script" (1999, p. 20:
>> http://web.archive.org/web/20120229131933/http://omega.enstb.org/yannis/pdf/boston99.pdf).
>>
>> According to Haralambous, on the second-level quotation marks (the
>> emphases are mine):
>>
>> #+begin_quote
>>
>> Also interesting is the case of the second level quotes. Here, quotes of
>> the size and shape of the English ones are used, but the opening quotes
>> are inverted, similar in form to raised small round guillemets [...].
>> Fortunately these quotes are provided by the Unicode standard (*U+201F*
>> and U+201D, the latter being the same closing double quotes as in
>> English); *the author knows no other language in which this combination
>> of double quotes might be used*.
>>
>> #+end_quote
>>
>>
>> So the problem is in the character U+201F (assuming Haralambous is
>> right). For the keywords `:utf8' and `html' no problem. But I don't know
>> what to put in `:latex' or in `:texinfo':
>>
>> #+begin_src emacs-lisp
>> (secondary-opening :utf-8 "‟" :html "‟;" :latex "??" :texinfo "??")
>> #+end_src
>>
>> In fact, I think latex2e has no command or shorthand predefined for this
>> character (see https://ibb.co/ZBGmwYP). There would be no problem with
>> LuaTeX and XeTeX. But this character would be difficult to obtain in
>> pdfTeX even using inputenc with the utf8 option.
>>
>> Best regards,
>>
>> Juan Manuel
>
> hi Juan,
>
> 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.
>
> cheers,
> Michalis
Hello Michalis, Juan Manuel,
[ I had no access to a computer and could not get to you sooner. Expect
timely replies from now on. ]
The first level quotes are indeed «». For the other two, I have to rely
on what I have encountered before, namely, that the second level is
denoted with double curly quotes “” and third with single curly quotes
‘’.
I have come across those in EU documents. There is a style guide for
the European Institutions.[1][2][3]
I do not know latex notation to help you with the technicalities.
Here are the unicode points:
| « | U+00AB |
| » | U+00BB |
| “ | U+201C |
| ” | U+201D |
| ‘ | U+2018 |
| ’ | U+2019 |
All the best,
Protesilaos
[1] Quotes: <http://publications.europa.eu/code/el/el-4100107el.htm>.
[2] General info: <http://publications.europa.eu/code/el/el-4100000.htm>.
[3] Main portal: <http://publications.europa.eu/code/el/el-000100.htm>.
--
Protesilaos Stavrou
https://protesilaos.com
^ permalink raw reply [relevance 3%]
* Re: Smart quotes for Greek (questions for a possible patch)
2021-08-27 16:23 3% ` Protesilaos Stavrou
@ 2021-08-31 11:11 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-31 11:11 UTC (permalink / raw)
To: Protesilaos Stavrou, mvar; +Cc: orgmode
Hello Protesilaos and Michalis,
Thank you very much, Protesilaos, for the valuable information. It can
be confirmed, then, that the quotation marks rules for current Greek are
identical to the rules for Spanish, so it will be enough to copy the
existing configuration for Spanish in `org-export-smart-quotes-alist'.
It seems that the character U+201F as the first second level quotes
(instead of U+201C), which Yannis Haralambous comments in the article
cited in my first message, although historically attested, has been
abandoned...
Soon I will propose here a patch to support small quotes to
Greek.
Best regards,
Juan Manuel
Protesilaos Stavrou writes:
> Hello Michalis, Juan Manuel,
>
> [ I had no access to a computer and could not get to you sooner. Expect
> timely replies from now on. ]
>
> The first level quotes are indeed «». For the other two, I have to rely
> on what I have encountered before, namely, that the second level is
> denoted with double curly quotes “” and third with single curly quotes
> ‘’.
>
> I have come across those in EU documents. There is a style guide for
> the European Institutions.[1][2][3]
>
> I do not know latex notation to help you with the technicalities.
> Here are the unicode points:
>
> | « | U+00AB |
> | » | U+00BB |
> | “ | U+201C |
> | ” | U+201D |
> | ‘ | U+2018 |
> | ’ | U+2019 |
>
> All the best,
> Protesilaos
>
> [1] Quotes: <http://publications.europa.eu/code/el/el-4100107el.htm>.
> [2] General info: <http://publications.europa.eu/code/el/el-4100000.htm>.
> [3] Main portal: <http://publications.europa.eu/code/el/el-000100.htm>.
^ permalink raw reply [relevance 9%]
* Re: Support for tabularray in LaTeX export
@ 2021-09-02 8:36 8% ` Juan Manuel Macías
2021-09-02 10:08 7% ` Vikas Rawal
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-02 8:36 UTC (permalink / raw)
To: Vikas Rawal; +Cc: orgmode
Hi Vikas,
You can define a modified version of `org-latex--org-table',
adding a new LaTeX attribute `:options'. Something like this:
#+begin_src emacs-lisp
(defun my/org-latex--org-table (table contents info)
"Return appropriate LaTeX code for an Org table.
TABLE is the table type element to transcode. CONTENTS is its
contents, as a string. INFO is a plist used as a communication
channel.
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
(let ((w (plist-get attr :width)))
(cond ((not w) "")
((member table-env '("tabular" "longtable")) "")
((member table-env '("tabu" "longtabu"))
(format (if (plist-get attr :spread) " spread %s "
" to %s ")
w))
(t (format "{%s}" w)))))
(caption (org-latex--caption/label-string table info))
(above? (org-latex--caption-above-p table info)))
(cond
((member table-env '("longtable" "longtabu"))
(let ((fontsize (let ((font (plist-get attr :font)))
(and font (concat font "\n")))))
(concat (and fontsize (concat "{" fontsize))
(format "\\begin{%s}%s{%s}\n" table-env width alignment)
(and above?
(org-string-nw-p caption)
(concat caption "\\\\\n"))
contents
(and (not above?)
(org-string-nw-p caption)
(concat caption "\\\\\n"))
(format "\\end{%s}" table-env)
(and fontsize "}"))))
(t
(let ((output (format "\\begin{%s}%s%s{%s}\n%s\\end{%s}"
table-env
(if opt opt "")
width
alignment
contents
table-env)))
(org-latex--decorate-table output attr caption above? info))))))
(advice-add 'org-latex--org-table :override #'my/org-latex--org-table)
#+end_src
and then:
#+ATTR_LATEX: :environment longtblr
#+ATTR_LATEX: :align <align-options>
#+ATTR_LATEX: :booktabs t
#+ATTR_LaTeX: :options [<options>]
Best regards,
Juan Manuel
Vikas Rawal writes:
> tabularray (CTAN: Package tabularray) provides longtblr environment
> that is called as
>
> ---
> \begin{longtblr}[various-table-options]{column and row specifications}
>
> \end{longtblr}
> ---
>
> Adding something like the following to orgmode tables makes them
> export nicely as longtblr
>
> ---
> #+ATTR_LATEX: :environment longtblr
> #+ATTR_LATEX: :align width=0.8\textwidth,colspec={lX[2,r]X[3,r]X
> [r,bg=gray9]}
> #+ATTR_LATEX: :booktabs t
> ---
>
> Everything seems to work very well with orgmode except that I cannot
> figure out how to pass [various table options] from orgmode. These
> table options include, most importantly, table notes.
>
> I normally use threeparttable for table notes, but longtblr does not
> seem to work with threeparttable and has its own syntax for table
> notes.
>
> Any advice on how to pass [table-options] to longtblr environment?
>
> Vikas
>
^ permalink raw reply [relevance 8%]
* Re: Support for tabularray in LaTeX export
2021-09-02 8:36 8% ` Juan Manuel Macías
@ 2021-09-02 10:08 7% ` Vikas Rawal
0 siblings, 0 replies; 200+ results
From: Vikas Rawal @ 2021-09-02 10:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 3992 bytes --]
This is perfect. Thank you, Juan Manuel.
Vikas
On Thu, 2 Sept 2021 at 14:06, Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi Vikas,
>
> You can define a modified version of `org-latex--org-table',
> adding a new LaTeX attribute `:options'. Something like this:
>
> #+begin_src emacs-lisp
> (defun my/org-latex--org-table (table contents info)
> "Return appropriate LaTeX code for an Org table.
>
> TABLE is the table type element to transcode. CONTENTS is its
> contents, as a string. INFO is a plist used as a communication
> channel.
>
> 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
> (let ((w (plist-get attr :width)))
> (cond ((not w) "")
> ((member table-env '("tabular" "longtable")) "")
> ((member table-env '("tabu" "longtabu"))
> (format (if (plist-get attr :spread) " spread %s "
> " to %s ")
> w))
> (t (format "{%s}" w)))))
> (caption (org-latex--caption/label-string table info))
> (above? (org-latex--caption-above-p table info)))
> (cond
> ((member table-env '("longtable" "longtabu"))
> (let ((fontsize (let ((font (plist-get attr :font)))
> (and font (concat font "\n")))))
> (concat (and fontsize (concat "{" fontsize))
> (format "\\begin{%s}%s{%s}\n" table-env width alignment)
> (and above?
> (org-string-nw-p caption)
> (concat caption "\\\\\n"))
> contents
> (and (not above?)
> (org-string-nw-p caption)
> (concat caption "\\\\\n"))
> (format "\\end{%s}" table-env)
> (and fontsize "}"))))
> (t
> (let ((output (format "\\begin{%s}%s%s{%s}\n%s\\end{%s}"
> table-env
> (if opt opt "")
> width
> alignment
> contents
> table-env)))
> (org-latex--decorate-table output attr caption above? info))))))
>
> (advice-add 'org-latex--org-table :override #'my/org-latex--org-table)
> #+end_src
>
> and then:
>
> #+ATTR_LATEX: :environment longtblr
> #+ATTR_LATEX: :align <align-options>
> #+ATTR_LATEX: :booktabs t
> #+ATTR_LaTeX: :options [<options>]
>
> Best regards,
>
> Juan Manuel
>
> Vikas Rawal writes:
>
> > tabularray (CTAN: Package tabularray) provides longtblr environment
> > that is called as
> >
> > ---
> > \begin{longtblr}[various-table-options]{column and row specifications}
> >
> > \end{longtblr}
> > ---
> >
> > Adding something like the following to orgmode tables makes them
> > export nicely as longtblr
> >
> > ---
> > #+ATTR_LATEX: :environment longtblr
> > #+ATTR_LATEX: :align width=0.8\textwidth,colspec={lX[2,r]X[3,r]X
> > [r,bg=gray9]}
> > #+ATTR_LATEX: :booktabs t
> > ---
> >
> > Everything seems to work very well with orgmode except that I cannot
> > figure out how to pass [various table options] from orgmode. These
> > table options include, most importantly, table notes.
> >
> > I normally use threeparttable for table notes, but longtblr does not
> > seem to work with threeparttable and has its own syntax for table
> > notes.
> >
> > Any advice on how to pass [table-options] to longtblr environment?
> >
> > Vikas
> >
>
[-- Attachment #2: Type: text/html, Size: 5197 bytes --]
^ permalink raw reply [relevance 7%]
* Re: Overlining troubles
@ 2021-09-18 12:50 5% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2021-09-18 12:50 UTC (permalink / raw)
To: emacs-orgmode
On 18/09/2021 15:14, Ypo wrote:
>
> I have tried many times in different ways to "overline" text. I am able
> to overline it on orgmode (I sacrificed the =verbatim= marker to achieve
> it), but it doesn't export overlined (nor HTML, nor LaTeX).
>
> I tried in the past to add it to "Org Emphasis Alist" but it didn't work.
>
> Is it possible to add overlining and to export it?
Just to avoid confusion, `org-emphasis-alist' is not designed to change
or to *add* new markers:
https://orgmode.org/list/87blatodir.fsf@nicolasgoaziou.fr/ (Nicolas
Goaziou, Mon, 05 Apr 2021 01:06:52 +0200, Re: Using backticks for the
inline code delimeter?)
If you wish to export =verbatim= text as text with line above, perhaps,
you can define custom "verbatim" export filter
"info (org) Advanced Export Configuration"
https://orgmode.org/manual/Advanced-Export-Configuration.html
A macro expanded with markup for particular backend (e.g. @@latex:
...@@) may be a better option
"info (org) Macro Replacement"
https://orgmode.org/manual/Macro-Replacement.html
Some people experimenting with custom link types with associated
handlers for particular export backends:
https://orgmode.org/list/87mtq9zatr.fsf@posteo.net/ (Juan Manuel Macías,
Mon, 26 Jul 2021 09:25:04 +0000, Multilingual quotes inside paragraphs).
Unfortunately you described what you have tried in too general words to
suggest something more specific.
^ permalink raw reply [relevance 5%]
* Re: Overlining troubles
[not found] <mailman.33.1631980810.21752.emacs-orgmode@gnu.org>
@ 2021-09-18 17:14 0% ` Ypo
0 siblings, 1 reply; 200+ results
From: Ypo @ 2021-09-18 17:14 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]
Thanks, Timothy and Max. I'll try to explain myself better.
Overlining is quite useful in math expressions, for example I needed it
to represent the arithmetic mean.
I need to be able to overline text and to export it overlined. The only
dirty solution I found was to change the =verbatim= mark, but now I
can't use verbatim on orgmode, and the overlined text isn't exported, so
unsustainable "solution".
The perfect solution? To be able to add a new marker to overline text
that can be exported overlined.
Best regards
:-)
El 18/09/2021 a las 18:00, emacs-orgmode-request@gnu.org escribió:
> Message: 7 Date: Sat, 18 Sep 2021 20:48:36 +0800 From: Timothy
> <tecosaur@gmail.com> To: Ypo <ypuntot@gmail.com> Cc:
> emacs-orgmode@gnu.org Subject: Re: Overlining troubles Message-ID:
> <87ee9mdp5i.fsf@gmail.com> Content-Type: text/plain; charset="utf-8"
> Hi Ypo, You’ll likely want to override `org-html-verbatim' and
> `org-latex-verbatim' to produce overlines in exports. All the best,
> Timothy -------------- next part -------------- An HTML attachment was
> scrubbed... URL:
> <https://lists.gnu.org/archive/html/emacs-orgmode/attachments/20210918/78086bf1/attachment.html>
> ------------------------------ Message: 8 Date: Sat, 18 Sep 2021
> 19:50:31 +0700 From: Max Nikulin <manikulin@gmail.com> To:
> emacs-orgmode@gnu.org Subject: Re: Overlining troubles Message-ID:
> <si4naq$47d$1@ciao.gmane.io> Content-Type: text/plain; charset=utf-8;
> format=flowed On 18/09/2021 15:14, Ypo wrote:
>> I have tried many times in different ways to "overline" text. I am able
>> to overline it on orgmode (I sacrificed the =verbatim= marker to achieve
>> it), but it doesn't export overlined (nor HTML, nor LaTeX).
>>
>> I tried in the past to add it to "Org Emphasis Alist" but it didn't work.
>>
>> Is it possible to add overlining and to export it?
> Just to avoid confusion, `org-emphasis-alist' is not designed to change
> or to*add* new markers:
>
> https://orgmode.org/list/87blatodir.fsf@nicolasgoaziou.fr/ (Nicolas
> Goaziou, Mon, 05 Apr 2021 01:06:52 +0200, Re: Using backticks for the
> inline code delimeter?)
>
> If you wish to export =verbatim= text as text with line above, perhaps,
> you can define custom "verbatim" export filter
> "info (org) Advanced Export Configuration"
> https://orgmode.org/manual/Advanced-Export-Configuration.html
>
> A macro expanded with markup for particular backend (e.g. @@latex:
> ...@@) may be a better option
> "info (org) Macro Replacement"
> https://orgmode.org/manual/Macro-Replacement.html
>
> Some people experimenting with custom link types with associated
> handlers for particular export backends:
> https://orgmode.org/list/87mtq9zatr.fsf@posteo.net/ (Juan Manuel Macías,
> Mon, 26 Jul 2021 09:25:04 +0000, Multilingual quotes inside paragraphs).
>
> Unfortunately you described what you have tried in too general words to
> suggest something more specific.
>
>
[-- Attachment #2: Type: text/html, Size: 5077 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Overlining troubles
@ 2021-09-18 17:51 0% ` Ypo
0 siblings, 0 replies; 200+ results
From: Ypo @ 2021-09-18 17:51 UTC (permalink / raw)
To: Timothy; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 3793 bytes --]
Hi!
I use orgmode to read and study directly but I am not able to set up
LaTeX preview. So I need something "direct", but I can't renounce to
exporting it.
So that you have an idea of what I'm dealing with, I am able to set up
LaTeX exporting on my home computer, but I can't make it work at my work
computer. LaTeX preview is almost a dream to me.
Best regards
El 18/09/2021 a las 19:32, Timothy escribió:
>
> Hi Ypo,
>
> If you’re thinking of maths, why not just write inline LaTeX, e.g.
> \(\bar{x}\) ?
>
> All the best,
> *Timothy*
>
> *From*: Ypo <mailto:"Ypo" <ypuntot@gmail.com>>
> *Subject*: Re: Overlining troubles
> *To*: emacs-orgmode@gnu.org <mailto:"emacs-orgmode@gnu.org"
> <emacs-orgmode@gnu.org>>
> *Date*: Sun, 19 Sep 2021 01:14:52 +0800
>
> Thanks, Timothy and Max. I'll try to explain myself better.
>
> Overlining is quite useful in math expressions, for example I needed
> it to represent the arithmetic mean.
>
> I need to be able to overline text and to export it overlined. The
> only dirty solution I found was to change the =verbatim= mark, but now
> I can't use verbatim on orgmode, and the overlined text isn't
> exported, so unsustainable "solution".
>
> The perfect solution? To be able to add a new marker to overline text
> that can be exported overlined.
>
> Best regards
>
> :-)
>
> El 18/09/2021 a las 18:00, emacs-orgmode-request@gnu.org escribió:
>> Message: 7 Date: Sat, 18 Sep 2021 20:48:36 +0800 From: Timothy
>> <tecosaur@gmail.com> To: Ypo <ypuntot@gmail.com> Cc:
>> emacs-orgmode@gnu.org Subject: Re: Overlining troubles Message-ID:
>> <87ee9mdp5i.fsf@gmail.com> Content-Type: text/plain; charset="utf-8"
>> Hi Ypo, You’ll likely want to override `org-html-verbatim' and
>> `org-latex-verbatim' to produce overlines in exports. All the best,
>> Timothy -------------- next part -------------- An HTML attachment
>> was scrubbed... URL:
>> <https://lists.gnu.org/archive/html/emacs-orgmode/attachments/20210918/78086bf1/attachment.html>
>> ------------------------------ Message: 8 Date: Sat, 18 Sep 2021
>> 19:50:31 +0700 From: Max Nikulin <manikulin@gmail.com> To:
>> emacs-orgmode@gnu.org Subject: Re: Overlining troubles Message-ID:
>> <si4naq$47d$1@ciao.gmane.io> Content-Type: text/plain; charset=utf-8;
>> format=flowed On 18/09/2021 15:14, Ypo wrote:
>>> I have tried many times in different ways to "overline" text. I am able
>>> to overline it on orgmode (I sacrificed the =verbatim= marker to achieve
>>> it), but it doesn't export overlined (nor HTML, nor LaTeX).
>>>
>>> I tried in the past to add it to "Org Emphasis Alist" but it didn't work.
>>>
>>> Is it possible to add overlining and to export it?
>> Just to avoid confusion, `org-emphasis-alist' is not designed to change
>> or to*add* new markers:
>>
>> https://orgmode.org/list/87blatodir.fsf@nicolasgoaziou.fr/ (Nicolas
>> Goaziou, Mon, 05 Apr 2021 01:06:52 +0200, Re: Using backticks for the
>> inline code delimeter?)
>>
>> If you wish to export =verbatim= text as text with line above, perhaps,
>> you can define custom "verbatim" export filter
>> "info (org) Advanced Export Configuration"
>> https://orgmode.org/manual/Advanced-Export-Configuration.html
>>
>> A macro expanded with markup for particular backend (e.g. @@latex:
>> ...@@) may be a better option
>> "info (org) Macro Replacement"
>> https://orgmode.org/manual/Macro-Replacement.html
>>
>> Some people experimenting with custom link types with associated
>> handlers for particular export backends:
>> https://orgmode.org/list/87mtq9zatr.fsf@posteo.net/ (Juan Manuel Macías,
>> Mon, 26 Jul 2021 09:25:04 +0000, Multilingual quotes inside paragraphs).
>>
>> Unfortunately you described what you have tried in too general words to
>> suggest something more specific.
>>
>>
[-- Attachment #2: Type: text/html, Size: 9516 bytes --]
^ permalink raw reply [relevance 0%]
* [PATCH] ox.el: add smart quotes for Greek
@ 2021-09-19 16:30 9% Juan Manuel Macías
2021-09-20 14:54 4% ` Max Nikulin
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.el: add smart quotes for Greek
2021-09-19 16:30 9% [PATCH] ox.el: add smart quotes for Greek Juan Manuel Macías
@ 2021-09-20 14:54 4% ` Max Nikulin
2021-09-21 20:20 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-09-20 14:54 UTC (permalink / raw)
To: orgmode; +Cc: Juan Manuel Macías
On 19/09/2021 23:30, Juan Manuel Macías wrote:
>
> 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
Since the choice of secondary opening quote character was uncertain at
first, I suppose, it would be nice to have this decision documented
somewhere in Org source repository for the case that it might be
revisited later. (Disclaimer: unsure that Org developers have the same
opinion.)
I mean the citation and the reference to the paper by Yannis Haralambous
to make clear that such variant was considered, the title of EU
recommendations since nobody has provided more authoritative reference
of Greek typography traditions.
Possible options:
- Add the note directly to the .el file. I am afraid, as inline comment
it could be considered too long.
- To a file in the "doc" directory dedicated to such decisions (there is
no such file yet however) with a reference from the .el file.
- Commit message. It is acceptable but not apparent for a person who
reads the code that git log may provide detailed explanation of
particular choice.
Mail archives are not permanent, e.g. web interface to Gmane was shut
down due to some problems, the same might happen with public inbox
mirrors. That is why, I think, a more detailed note should be added to
Org sources.
By the way, Common Locale Data Repository https://cldr.unicode.org/
defines U+201C (“) and U+201D (”) characters as well
ag quotation common/main/el*
common/main/el.xml
1224: <quotationStart>«</quotationStart>
1225: <quotationEnd>»</quotationEnd>
1226: <alternateQuotationStart>“</alternateQuotationStart>
1227: <alternateQuotationEnd>”</alternateQuotationEnd>
Unfortunately this part of Unicode databases is not available form Emacs.
^ permalink raw reply [relevance 4%]
* Re: [PATCH] ox.el: add smart quotes for Greek
2021-09-20 14:54 4% ` Max Nikulin
@ 2021-09-21 20:20 8% ` Juan Manuel Macías
2021-09-22 17:19 5% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-21 20:20 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Hi Maxim,
Max Nikulin writes:
> [...]
> Possible options:
> - Add the note directly to the .el file. I am afraid, as inline
> comment it could be considered too long.
> - To a file in the "doc" directory dedicated to such decisions (there
> is no such file yet however) with a reference from the .el file.
> - Commit message. It is acceptable but not apparent for a person who
> reads the code that git log may provide detailed explanation of
> particular choice.
Thanks for your suggestions. Maybe I could add a link to the Haralambous
paper in the commit message, along with a very short note... In any
case, the only issue is with the second level opening quotes.
Haralambous asserts that the (pretty rare) character U+201F must be
used, and not the character U+201C, which is the one used in English
(among many other languages) and in Spanish second level quotes, and the
one that I have applied (proposed by Protesilaos) to the patch.
Haralambous is a great TeX guru, and a great scholar and theorist of
Greek typography, but... I would say that in this case his mind is more
focused on a historical tradition probably abandoned before the digital
age. I really don't know. Moreover, it is difficult to find specimens of
the use of second-level quotation marks. I have looked in Greek books
printed in the early and middle of the last century, and I have not
found anything. My suspicion is that in Greek nowadays the character
U+201C (common in other languages ---as I said before--- and therefore
better known) has ended up standardizing for second level opening
quotes. Maybe all the above could be summarized in less than one line
inside the commit message ;-). A quick search, by the way, of the term
'εισαγωγικά' (= 'quotation marks') on www.greek-language.gr returns this
result, where it is seen clearly the character U+201C:
... (« » ή “ ”) ...
https://www.greek-language.gr/greekLang/modern_greek/tools/lexica/search.html?lq=%CE%B5%CE%B9%CF%83%CE%B1%CE%B3%CF%89%CE%B3%CE%B9%CE%BA%CE%AC
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [ANN] org-ql 0.6 released
@ 2021-09-22 12:10 10% ` Juan Manuel Macías
2021-09-22 22:41 6% ` Adam Porter
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-22 12:10 UTC (permalink / raw)
To: Adam Porter; +Cc: orgmode
Hi Adam,
Thank you very much for this great package. I could no longer live without
org-ql/helm-org-ql :-)
Best regards,
Juan Manuel
Adam Porter writes:
> Hi friends,
>
> FYI, I just released version 0.6 of org-ql. Please see the changelog
> here:
>
> https://github.com/alphapapa/org-ql#06
^ permalink raw reply [relevance 10%]
* Re: [PATCH] ox.el: add smart quotes for Greek
2021-09-21 20:20 8% ` Juan Manuel Macías
@ 2021-09-22 17:19 5% ` Max Nikulin
2021-09-22 19:55 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-09-22 17:19 UTC (permalink / raw)
To: emacs-orgmode
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.
> -`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.
On 22/09/2021 03:20, Juan Manuel Macías wrote:
>> [...]
>> Possible options:
>> - Add the note directly to the .el file. I am afraid, as inline
>> comment it could be considered too long.
>> - To a file in the "doc" directory dedicated to such decisions (there
>> is no such file yet however) with a reference from the .el file.
>> - Commit message. It is acceptable but not apparent for a person who
>> reads the code that git log may provide detailed explanation of
>> particular choice.
> ...
> Haralambous is a great TeX guru, and a great scholar and theorist of
> Greek typography, but... I would say that in this case his mind is more
> focused on a historical tradition probably abandoned before the digital
> age.
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.
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox.el: add smart quotes for Greek
2021-09-22 17:19 5% ` Max Nikulin
@ 2021-09-22 19:55 8% ` Juan Manuel Macías
2021-09-23 16:10 6% ` Max Nikulin
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%]
* Re: [PATCH] Fix some typos
@ 2021-09-22 20:18 10% ` Juan Manuel Macías
2021-09-23 14:49 6% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-22 20:18 UTC (permalink / raw)
To: Max Nikulin, Marco Wahl; +Cc: orgmode
Hi all:
Max Nikulin writes:
> Please, forgive my ignorance of Shakespeare's poetry.
>
> On 17/09/2021 17:05, Marco Wahl wrote:
>>> On 17/09/2021 04:40, Stefan Kangas wrote:
>>
>>>> Please find attached another clean-up patch that fixes a small
>>>> number of typos. > > Thou shall not change "memeory" to "memory" tho
> I think, a bit more is required to avoid recurring attempts to change
> spelling if you would like to see such variant. Static code analyzers
> usually have a feature that allows to ignore specific warning at a
> particular line, see e.g.
> https://flake8.pycqa.org/en/latest/user/violations.html#in-line-ignoring-errors
> for Python's flake8.
>
> Maybe "LocalWords:" could do a similar trick for ispell.el at least
> for the whole file. Unsure if it is possible to add an exception for
> the quote only.
>
> However there is namely "memory" in the "1609 Quarto", see e.g.
> https://en.wikipedia.org/wiki/Sonnet_1 Web pages with the same variant
> as in the Org manual do not mention the source (particular edition). I
> hope, I just do not know what is considered as the canonical variant
> for not so old language.
I am not an expert on Shakespeare's poetry either, but as the author of
the patch where Sonnet 1 is included, I can say that 'memeory' is a typo
(sorry). At least I didn't use that word intentionally. I don't know if
there is any textual variant 'memeory', but in my case it is nothing
more than a simple typo :-).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [ANN] org-ql 0.6 released
2021-09-22 12:10 10% ` Juan Manuel Macías
@ 2021-09-22 22:41 6% ` Adam Porter
0 siblings, 0 replies; 200+ results
From: Adam Porter @ 2021-09-22 22:41 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Adam,
>
> Thank you very much for this great package. I could no longer live without
> org-ql/helm-org-ql :-)
Hi Juan,
Thanks for the kind words. I'm glad it's useful to you. :)
^ permalink raw reply [relevance 6%]
* Re: [PATCH] Fix some typos
2021-09-22 20:18 10% ` Juan Manuel Macías
@ 2021-09-23 14:49 6% ` Max Nikulin
2021-09-24 6:03 0% ` Loris Bennett
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-09-23 14:49 UTC (permalink / raw)
To: Juan Manuel Macías, Marco Wahl; +Cc: orgmode
On 23/09/2021 03:18, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
>> However there is namely "memory" in the "1609 Quarto", see e.g.
>> https://en.wikipedia.org/wiki/Sonnet_1 Web pages with the same variant
>> as in the Org manual do not mention the source (particular edition). I
>> hope, I just do not know what is considered as the canonical variant
>> for not so old language.
>
> I am not an expert on Shakespeare's poetry either, but as the author of
> the patch where Sonnet 1 is included, I can say that 'memeory' is a typo
> (sorry). At least I didn't use that word intentionally. I don't know if
> there is any textual variant 'memeory', but in my case it is nothing
> more than a simple typo :-).
Then "mught" should be another typo.
"His tender heire might beare his memory:" - 1609 Quatro
"His tender heir might bear his memory:" - Wikipedia citing Shakespeare,
William. Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury
Arden 2010. p. 113 ISBN 9781408017975
"His tender heir mught bear his memeory:" - some web pages and Org manual.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] ox.el: add smart quotes for Greek
2021-09-22 19:55 8% ` Juan Manuel Macías
@ 2021-09-23 16:10 6% ` Max Nikulin
2021-09-23 17:17 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-09-23 16:10 UTC (permalink / raw)
To: emacs-orgmode; +Cc: orgmode
On 23/09/2021 02:55, Juan Manuel Macías wrote:
>
> 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...
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.
Some degree of uncertainty during software development is unavoidable,
so it is perfectly OK to proceed with the variant you have proposed. It
is better to address other issues.
I suggest just to document the decision, to mention pros and cons. There
is a little chance that the decision might be reconsidered later and it
is not a problem. It would be nice to provide useful hints for
participants of future discussion. Even information that another
language was added not just for completeness and with guessed values
might be helpful.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] ox.el: add smart quotes for Greek
2021-09-23 16:10 6% ` Max Nikulin
@ 2021-09-23 17:17 8% ` Juan Manuel Macías
2021-09-25 19:56 7% ` Juan Manuel Macías
0 siblings, 1 reply; 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: [PATCH] Fix some typos
2021-09-23 14:49 6% ` Max Nikulin
@ 2021-09-24 6:03 0% ` Loris Bennett
2021-09-24 12:23 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Loris Bennett @ 2021-09-24 6:03 UTC (permalink / raw)
To: emacs-orgmode
Max Nikulin <manikulin@gmail.com> writes:
> On 23/09/2021 03:18, Juan Manuel Macías wrote:
>> Max Nikulin writes:
>>
>>> However there is namely "memory" in the "1609 Quarto", see e.g.
>>> https://en.wikipedia.org/wiki/Sonnet_1 Web pages with the same variant
>>> as in the Org manual do not mention the source (particular edition). I
>>> hope, I just do not know what is considered as the canonical variant
>>> for not so old language.
>>
>> I am not an expert on Shakespeare's poetry either, but as the author of
>> the patch where Sonnet 1 is included, I can say that 'memeory' is a typo
>> (sorry). At least I didn't use that word intentionally. I don't know if
>> there is any textual variant 'memeory', but in my case it is nothing
>> more than a simple typo :-).
>
> Then "mught" should be another typo.
>
> "His tender heire might beare his memory:" - 1609 Quatro
I think "Quatro" is another typo and should be "Quarto" (unless there
is a typo in the date and it is a line from little-know song by Suzi ...)
> "His tender heir might bear his memory:" - Wikipedia citing Shakespeare,
> William. Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden
> 2010. p. 113 ISBN 9781408017975
>
> "His tender heir mught bear his memeory:" - some web pages and Org manual.
>
>
--
This signature is currently under construction.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] Fix some typos
2021-09-24 6:03 0% ` Loris Bennett
@ 2021-09-24 12:23 7% ` Juan Manuel Macías
2021-09-25 11:08 6% ` Marco Wahl
2021-09-25 11:47 6% ` [PATCH] org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and another, typo Max Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-24 12:23 UTC (permalink / raw)
To: Loris Bennett, Max Nikulin, Marco Wahl; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]
I attach a patch with Shakespeare's sonnet completely fixed: the poem is
replaced by the version included in Wikipedia (Shakespeare, William.
Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden 2010.
p. 113). I also removed a spurious phrase that I put in that patch
(Org-News).
Best regards,
Juan Manuel
Loris Bennett writes:
> Max Nikulin <manikulin@gmail.com> writes:
>
>> On 23/09/2021 03:18, Juan Manuel Macías wrote:
>>> Max Nikulin writes:
>>>
>>>> However there is namely "memory" in the "1609 Quarto", see e.g.
>>>> https://en.wikipedia.org/wiki/Sonnet_1 Web pages with the same variant
>>>> as in the Org manual do not mention the source (particular edition). I
>>>> hope, I just do not know what is considered as the canonical variant
>>>> for not so old language.
>>>
>>> I am not an expert on Shakespeare's poetry either, but as the author of
>>> the patch where Sonnet 1 is included, I can say that 'memeory' is a typo
>>> (sorry). At least I didn't use that word intentionally. I don't know if
>>> there is any textual variant 'memeory', but in my case it is nothing
>>> more than a simple typo :-).
>>
>> Then "mught" should be another typo.
>>
>> "His tender heire might beare his memory:" - 1609 Quatro
>
> I think "Quatro" is another typo and should be "Quarto" (unless there
> is a typo in the date and it is a line from little-know song by Suzi ...)
>
>> "His tender heir might bear his memory:" - Wikipedia citing Shakespeare,
>> William. Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden
>> 2010. p. 113 ISBN 9781408017975
>>
>> "His tender heir mught bear his memeory:" - some web pages and Org manual.
>>
>>
[-- Attachment #2: 0001-org-manual.org-ORG-NEWS-fix-Shakespeare-sonnet-and-a.patch --]
[-- Type: text/x-patch, Size: 3153 bytes --]
From f2e09b5e50a08b409e5f48df59dffbb36e9677ac Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 24 Sep 2021 13:58:30 +0200
Subject: [PATCH] org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and another
typo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* doc/org-manual.org (Verse blocks in LaTeX export): The previous
version of Shakespeare's sonnet is replaced by the version included in
Wikipedia (Shakespeare, William. Duncan-Jones, Katherine. Shakespeare’s
Sonnets. Bloomsbury Arden 2010. p. 113)
* etc/ORG-NEWS (Support verse blocks in LaTeX export): The last
sentence is superfluous. There is no explanation below.
---
doc/org-manual.org | 17 +++++++++--------
etc/ORG-NEWS | 3 +--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index b5de85cc9..ba396e205 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13897,24 +13897,25 @@ explained below.
- =:latexcode= :: It accepts any arbitrary LaTeX code that can be
included within a LaTeX =verse= environment.
-A complete example with Shakespeare's first sonnet:
+A complete example with Shakespeare's first sonnet (source:
+[[https://en.wikipedia.org/wiki/Sonnet_1]]):
#+begin_src org
,#+ATTR_LATEX: :center t :latexcode \color{red} :lines 5
-,#+ATTR_LATEX: :versewidth Feed’st thy light’st flame with self-substantial fuel,
+,#+ATTR_LATEX: :versewidth Feed’st thy light’s flame with self-substantial fuel,
,#+BEGIN_VERSE
From fairest creatures we desire increase,
That thereby beauty’s rose might never die,
-But as the riper should by time decrease,
-His tender heir mught bear his memeory:
+But as the riper should by time decease
+His tender heir might bear his memory:
But thou, contracted to thine own bright eyes,
-Feed’st thy light’st flame with self-substantial fuel,
+Feed’st thy light’s flame with self-substantial fuel,
Making a famine where abundance lies,
Thyself thy foe, to thy sweet self too cruel.
-Thou that art now the world’s fresh ornament
+Thou that art now the world’s fresh ornament,
And only herald to the gaudy spring,
-Within thine own bud buriest thy content
-And, tender churl, makest waste in niggarding.
+Within thine own bud buriest thy content,
+And, tender churl, mak’st waste in niggardly.
Pity the world, or else this glutton be,
To eat the world’s due, by the grave and thee.
,#+END_VERSE
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 7a46e825b..9a674cc04 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -254,8 +254,7 @@ that Org mode configures LaTeX to process any new float type.
The LaTeX export back-end accepts four attributes for verse blocks:
=:lines=, =:center=, =:versewidth= and =:latexcode=. The three first
require the external LaTeX package =verse.sty=, which is an extension
-of the standard LaTeX environment. The purpose of these attributes is
-explained below.
+of the standard LaTeX environment.
*** Support quote blocks in LaTeX export
--
2.32.0
^ permalink raw reply related [relevance 7%]
* Re: [PATCH] Fix some typos
2021-09-24 12:23 7% ` Juan Manuel Macías
@ 2021-09-25 11:08 6% ` Marco Wahl
2021-09-25 11:47 6% ` [PATCH] org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and another, typo Max Nikulin
1 sibling, 0 replies; 200+ results
From: Marco Wahl @ 2021-09-25 11:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Loris Bennett, orgmode, Max Nikulin
Please don't top post! Hopefully there is consent about using the
bottom posting style on this list.
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I attach a patch with Shakespeare's sonnet completely fixed: the poem is
> replaced by the version included in Wikipedia (Shakespeare, William.
> Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden 2010.
> p. 113). I also removed a spurious phrase that I put in that patch
> (Org-News).
Thanks for the patch!
I agree to change the Shakespeare part to have a reference and be
corrected accordingly.
Thanks for the fix of the ORGNEWS entry. Nitpick: I'd prefer the fix of
the ORGNEWS in a further patch for a little bit of more clarity.
AFAICS thy patch mught apply!
^ permalink raw reply [relevance 6%]
* Re: [PATCH] org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and another, typo
2021-09-24 12:23 7% ` Juan Manuel Macías
2021-09-25 11:08 6% ` Marco Wahl
@ 2021-09-25 11:47 6% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2021-09-25 11:47 UTC (permalink / raw)
To: emacs-orgmode
On 24/09/2021 19:23, Juan Manuel Macías wrote:
> I attach a patch with Shakespeare's sonnet completely fixed: the poem is
> replaced by the version included in Wikipedia (Shakespeare, William.
> Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden 2010.
> p. 113).
Thank you, Juan Manuel. With you patch the text becomes almost identical to
- Shakespeare's Sonnets (1883) William Shakespeare, edited by William
J. Rolfe
https://en.wikisource.org/wiki/Shakespeare%27s_Sonnets_(1883)/Sonnet_1
- Shakespeare's Sonnets (1923) William Shakespeare, edited by Edward
Bliss Reed
https://en.wikisource.org/wiki/Shakespeare%27s_Sonnets_(1923)_Yale/Text/Sonnet_1
I think, variations are not significant: "niggardly" / "niggarding" and
a few more commas in the older editions.
I hope, Unicode single comma apostrophe U+2019 (right single quotation
mark) is not a problem (vs. \x27 ASCII character). Anyway it is used in
the current variant and nobody complains.
I think, the patch should be applied to avoid proliferation of a variant
with strange spelling in the web.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] ox.el: add smart quotes for Greek
2021-09-23 17:17 8% ` Juan Manuel Macías
@ 2021-09-25 19:56 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-25 19:56 UTC (permalink / raw)
To: orgmode; +Cc: Max Nikulin
[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]
Hi again,
I am attaching a new version of the patch, with some typos fixed and a
explanatory note in the commit message on the choice of the character
U+201C as Greek second-level opening quotes.
In case anyone is interested in what Yanis Haralambous answered me in a
recent mail, I reproduce here (with his permission) a fragment of the
message:
#+begin_quote
[...] to answer your question, the average Greek writer would use
U+201C. For those that seek Greek typographic tradition, there should be
a substitution [...], but it would be more appropriate to do it
on the glyph level. From a grapholinguistic point of view there is
absolutely no need of using U+201F, the difference should be on the
alllographic level, the grapheme should only carry the information
"CLOSING DOUBLE SECOND-LEVEL QUOTATION MARK" and U+201C is a good choice
for representing that grapheme since it is used in most countries of the
world…
#+end_quote
Therefore, if someone wishes to use the historical character [in a
LuaTeX or XeTeX document] (represented by U+201F), I agree with Yannis
that it is better to use that symbol at the glyph level and not at the
character level. For this scenario a GSUB opentype feature would work
very well, since it is a historical character (as in the case of
historical ligatures, alternate glyphs, etc.).
Best regards,
Juan Manuel
[-- Attachment #2: 0001-ox.el-add-smart-quotes-for-greek.patch --]
[-- Type: text/x-patch, Size: 2062 bytes --]
From 86edfd424d01a08cc277540644e0cdc7df075b72 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 25 Sep 2021 20:41:43 +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, who
has contributed a style guide for the European institutions:
http://publications.europa.eu/code/el/el-4100107el.htmq On the correct
character for Greek second-level opening quotes, according to Yannis
Haralambous (`From Unicode to Typography, a Case Study: the Greek
Script' (1999, p. 20), a symbol equivalent to the Unicode character
U+201F is historically attested. But it seems that the current trend
in Greece is to apply the character U+201C, more commonly used in
other languages. Haralambous himself, in a recent consultation,
states: `[...] U+201C is a good choice for representing that grapheme
since it is used in most countries of the world...'
---
lisp/ox.el | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/lisp/ox.el b/lisp/ox.el
index 18b13a326..89a3ff5f1 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -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.33.0
^ permalink raw reply related [relevance 7%]
* Re: [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% ` [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
@ 2021-09-26 6:08 6% ` Bastien
2021-09-26 11:35 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Bastien @ 2021-09-26 6:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> As a possible solution I'm attaching this patch (little tested).
I could not apply the patch in the bugfix or main branch. Is it still
relevant? If the bug is still here, feel free to send an updated patch.
Thanks!
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [PATCH] org.el: use only link descriptions in indirect buffer names
2021-05-23 11:25 9% ` Juan Manuel Macías
@ 2021-09-26 7:40 6% ` Bastien
0 siblings, 0 replies; 200+ results
From: Bastien @ 2021-09-26 7:40 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Ihor Radchenko
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> (new patch attached)
I see this patch has been applied, thanks to both of you.
I'm marking it as applied for updates.orgmode.org.
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.)
2021-09-26 6:08 6% ` Bastien
@ 2021-09-26 11:35 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-26 11:35 UTC (permalink / raw)
To: Bastien; +Cc: orgmode
Hi Bastien, thank you for your message,
Bastien writes:
> I could not apply the patch in the bugfix or main branch. Is it still
> relevant? If the bug is still here, feel free to send an updated patch.
I have consulted the log, and the patch was already applied by Nicololas
in commit:
40a20136d * | | Prevent partial fontification when a link is displayed full
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
Results 201-400 of ~1600 next (newer) | prev (older) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
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 6% ` Bastien
2021-05-01 11:46 10% ` Juan Manuel Macías
[not found] ` <87tunlxws3.fsf@ucl.ac.uk>
2021-05-02 11:09 9% ` Juan Manuel Macías
2021-05-08 7:31 6% ` Juan Manuel Macías
2021-05-15 13:46 6% ` Bastien
2021-05-01 10:58 6% ` Timothy
2021-01-31 19:37 [patch] to allow org-attach-git to handle individual repositories Juan Manuel Macías
2021-04-28 3:57 6% ` Bastien
2021-04-28 13:42 10% ` Juan Manuel Macías
2021-05-15 14:08 6% ` Bastien
2021-02-18 16:33 [PATCH] Startup option to separate macros arguments with an alternative string Juan Manuel Macías
2021-04-19 9:19 ` Nicolas Goaziou
2021-04-21 16:01 4% ` Juan Manuel Macías
2021-04-22 12:55 5% ` Nicolas Goaziou
2021-04-22 13:46 10% ` Juan Manuel Macías
2021-04-25 3:46 6% ` Timothy
2021-04-02 18:15 [Patch] to correctly sort the items with emphasis marks in a list Juan Manuel Macías
2021-04-09 22:28 ` Nicolas Goaziou
2021-04-10 0:01 ` Juan Manuel Macías
2021-04-17 13:27 ` Maxim Nikulin
2021-04-18 17:52 ` Juan Manuel Macías
2021-04-18 21:20 ` 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 ` Juan Manuel Macías
2021-04-24 14:41 5% ` Maxim Nikulin
2021-04-28 5:46 6% ` Bastien
2021-04-28 6:37 0% ` Nicolas Goaziou
2021-04-05 9:25 [tip] search this mailing list with helm-surfraw Juan Manuel Macías
2021-04-25 5:00 7% ` Bastien
2021-04-27 20:20 10% ` Juan Manuel Macías
2021-04-30 13:26 6% [PATCH] Possibility of using alternative separators in macros Juan Manuel Macías
2021-05-01 8:30 ` Bastien
2021-05-01 10:04 ` Nicolas Goaziou
2021-05-01 21:50 8% ` Juan Manuel Macías
2021-05-02 21:08 5% ` Christian Moe
2021-05-11 11:01 5% ` Eric S Fraga
2021-05-11 16:12 5% ` 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 6% ` Bastien
2021-05-15 20:14 9% ` Juan Manuel Macías
2021-05-15 20:25 6% ` Bastien
2021-05-15 21:05 10% ` Juan Manuel Macías
2021-05-16 12:17 6% ` Bastien
2021-05-16 16:48 0% ` Maxim Nikulin
2021-04-30 15:19 How to create a macro that inserts multiline text with :B_ignoreheading: tag? Richard Stanton
2021-04-30 20:40 10% ` Juan Manuel Macías
2021-04-30 23:40 3% ` Richard Stanton
2021-05-02 20:20 8% About multilingual documents Juan Manuel Macías
2021-05-03 6:58 5% ` Aleksandar Dimitrov
2021-05-03 20:33 9% ` Juan Manuel Macías
2021-05-04 8:44 2% ` Aleksandar Dimitrov
2021-05-06 11:11 6% ` Juan Manuel Macías
2021-05-10 7:19 8% [tip] Export annotations with the 'Mindflow' LaTeX package Juan Manuel Macías
2021-05-16 15:31 8% [Question] Custom parse tree filter Juan Manuel Macías
2021-05-16 15:59 5% ` Nicolas Goaziou
2021-05-17 12:20 8% ` Juan Manuel Macías
2021-05-17 15:41 8% Multilingual support (proposals and state of the question) Juan Manuel Macías
2021-05-17 16:03 6% ` Denis Maier
2021-05-17 18:10 10% ` Juan Manuel Macías
2021-05-20 7:14 can't install footnotes in certain table cells Uwe Brauer
2021-05-20 9:57 ` [can't insert footnotes in all table cells] (was: can't install footnotes in certain table cells) Uwe Brauer
2021-05-20 10:06 ` [org-footnote--allow-reference-p] (was: [can't insert footnotes in all table cells]) Uwe Brauer
2021-05-20 10:17 10% ` [org-footnote--allow-reference-p] Juan Manuel Macías
2021-05-20 10:21 0% ` [org-footnote--allow-reference-p] Uwe Brauer
2021-05-20 10:38 10% ` [org-footnote--allow-reference-p] Juan Manuel Macías
2021-05-20 11:45 8% An attempt to prepare critical editions within Org Juan Manuel Macías
2021-05-20 12:24 6% ` Denis Maier
2021-05-22 14:12 9% [PATCH] org.el: use only link descriptions in indirect buffer names Juan Manuel Macías
2021-05-23 10:41 6% ` Ihor Radchenko
2021-05-23 11:25 9% ` Juan Manuel Macías
2021-09-26 7:40 6% ` Bastien
2021-05-24 12:14 7% [PATCH] ox-latex.el: add LaTeX attributes to quote block Juan Manuel Macías
2021-05-25 9:21 5% ` Nicolas Goaziou
2021-05-25 12:42 8% ` Juan Manuel Macías
2021-05-25 15:52 6% ` Nicolas Goaziou
2021-05-25 20:50 7% ` Juan Manuel Macías
2021-05-26 21:05 5% ` Nicolas Goaziou
2021-05-26 23:02 6% ` Juan Manuel Macías
2021-05-29 20:22 6% ` Nicolas Goaziou
2021-05-28 2:54 Smart quotes not working correctly with single quotes Andreas Gösele
2021-05-28 10:10 9% ` Juan Manuel Macías
2021-05-28 15:42 7% ` Andreas Gösele
2021-05-28 17:02 9% ` Juan Manuel Macías
2021-05-28 20:27 7% ` Andreas Gösele
2021-05-28 20:37 10% ` Juan Manuel Macías
2021-05-29 2:42 6% ` Andreas Gösele
2021-05-28 17:55 0% ` Albert Krewinkel
2021-05-28 19:48 ` Nicolas Goaziou
2021-05-28 20:19 10% ` Juan Manuel Macías
2021-05-30 17:33 TMIO Pre-release, request for feedback Timothy
2021-05-30 19:42 10% ` Juan Manuel Macías
2021-05-31 10:40 9% An attempt to convert Elfeed entries (with parameters) to Org trees Juan Manuel Macías
2021-06-23 14:56 6% ` Ihor Radchenko
2021-06-24 8:02 10% ` Juan Manuel Macías
2021-06-01 15:36 suggestion to change default org-latex-pdf-process to latexmk Bruce D'Arcus
2021-06-01 15:52 10% ` Juan Manuel Macías
2021-06-02 0:00 ` Tim Cross
2021-06-02 6:07 ` Stefan Nobis
2021-06-02 8:40 10% ` Juan Manuel Macías
2021-06-02 2:03 Format babel code block for export? Galaxy Being
2021-06-02 9:42 10% ` Juan Manuel Macías
2021-06-03 14:54 10% Remove all Org metadata with header argument `:comments org' Juan Manuel Macías
2021-06-20 13:58 6% ` Ihor Radchenko
2021-06-03 21:11 10% [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part Juan Manuel Macías
2021-06-04 11:31 13% ` Juan Manuel Macías
2021-06-06 22:34 13% ` Juan Manuel Macías
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
2021-09-26 6:08 6% ` Bastien
2021-09-26 11:35 10% ` Juan Manuel Macías
2021-06-06 18:19 [PATCH] Allow LaTeX reference command (\ref) to be customised Timothy
2021-06-06 18:29 10% ` Juan Manuel Macías
2021-06-07 11:43 literate programming, development log -- ideas? Greg Minshall
2021-06-07 12:00 10% ` Juan Manuel Macías
2021-06-07 13:09 10% org-critical-edition (a package for philologists and classicists) Juan Manuel Macías
2021-06-14 8:50 6% ` Christian Moe
2021-06-15 12:44 9% ` Juan Manuel Macías
2021-06-08 15:49 org-attach a directory? John Kitchin
2021-06-08 16:21 ` Henrik Frisk
2021-06-08 20:41 ` John Kitchin
2021-06-09 1:38 6% ` [patch] " Juan Manuel Macías
2021-06-11 1:43 ` stardiviner
2021-06-11 16:35 ` John Kitchin
2021-06-11 17:10 4% ` Juan Manuel Macías
2021-06-08 17:15 literate programming, development log -- ideas? (ominbus reply) Greg Minshall
2021-06-08 17:21 ` Samuel Banya
2021-06-09 8:59 ` Eric S Fraga
2021-06-09 22:21 ` Dr. Arne Babenhauserheide
2021-06-10 22:07 ` Samuel Wales
2021-06-11 0:13 ` Samuel Banya
2021-06-11 14:30 10% ` Juan Manuel Macías
2021-06-11 15:02 6% ` Samuel Banya
2021-06-09 19:35 org-attach a directory? Ypo
2021-06-09 23:39 ` John Kitchin
2021-06-10 3:56 ` Ypo
2021-06-10 12:37 ` Christian Barthel
2021-06-10 14:01 10% ` Juan Manuel Macías
2021-06-10 16:13 13% ` Juan Manuel Macías
2021-06-11 17:53 Failure to resolve internal links on ox-html export? Tim Visher
2021-06-11 18:31 10% ` Juan Manuel Macías
2021-06-18 19:47 6% ` Tim Visher
2021-06-18 20:37 10% ` Juan Manuel Macías
2021-06-18 22:18 0% ` Tim Cross
2021-06-20 15:01 0% ` Tim Visher
2021-06-12 9:15 Write Markdown in Org mode leo
2021-06-12 12:35 9% ` Juan Manuel Macías
2021-06-12 15:14 6% ` leo
2021-06-12 15:51 10% ` Juan Manuel Macías
2021-06-12 23:51 7% [tip] LaTeX preview of a region Juan Manuel Macías
2021-06-16 9:33 no inline images anymore after reinstall Prof. Dr. Johanna May
2021-06-16 12:51 9% ` Juan Manuel Macías
2021-06-17 12:06 example paper written in org completely Eric S Fraga
2021-06-17 12:51 10% ` Juan Manuel Macías
2021-06-18 12:11 9% A dictionary made in Org Mode Juan Manuel Macías
2021-06-18 12:19 6% ` John Kitchin
2021-06-18 12:27 6% ` Detlef Steuer
2021-06-18 13:51 6% ` Samuel Banya
2021-06-18 22:15 publishing: no default publishing function, or symbol is not defined Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 12:48 10% ` Juan Manuel Macías
2021-06-19 18:23 5% ` Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 18:28 5% ` [External Email] " Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 19:32 9% ` Juan Manuel Macías
2021-06-22 20:26 7% ` Christopher W. Ryan via General discussions about Org-mode.
2021-06-25 8:38 10% ` Juan Manuel Macías
2021-06-23 19:27 appearance of list as results from evaluating code blocks Johannes Brauer
2021-06-23 19:43 10% ` Juan Manuel Macías
2021-06-23 20:03 3% ` Johannes Brauer
2021-06-26 14:44 Export Org mode files to (gag, barf) MS Office? Brandon Taylor
2021-06-26 15:15 10% ` Juan Manuel Macías
2021-06-29 11:25 Virtually prefix headlines according to content Rodrigo Morales
2021-06-29 13:34 10% ` Juan Manuel Macías
2021-06-29 13:53 5% ` John Kitchin
2021-06-29 20:44 0% ` Samuel Wales
2021-07-05 19:44 convert subtree or nested list to table Matt Price
2021-07-05 20:01 10% ` 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-07-07 6:18 0% ` Uwe Brauer
2021-07-07 18:27 10% ` Juan Manuel Macías
2021-07-07 18:44 0% ` Uwe Brauer
2021-07-07 21:16 6% ` Matt Price
2021-07-09 9:15 10% [PATCH] [BUG] Bad fontification in full displayed links Juan Manuel Macías
2021-07-10 1:50 6% ` Ihor Radchenko
2021-07-10 12:12 10% ` Juan Manuel Macías
2021-07-27 20:02 6% ` Nicolas Goaziou
2021-07-10 13:42 org-mode export to (latex) PDF Jean-Christophe Helary
2021-07-10 13:52 10% ` Juan Manuel Macías
2021-07-10 14:13 2% ` Jean-Christophe Helary
2021-07-10 14:38 8% ` Juan Manuel Macías
2021-07-10 14:59 4% ` Tim Cross
2021-07-10 17:40 8% ` Juan Manuel Macías
2021-07-12 3:09 4% ` Tim Cross
2021-07-10 15:01 1% ` Jean-Christophe Helary
2021-07-10 16:13 6% ` 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 3% ` Maxim Nikulin
2021-07-14 19:05 ` Stefan Nobis
2021-07-14 23:26 ` Tim Cross
2021-07-15 12:06 8% ` Juan Manuel Macías
2021-07-15 17:10 ` Maxim Nikulin
2021-07-15 19:40 9% ` Juan Manuel Macías
2021-07-16 16:56 5% ` Maxim Nikulin
2021-07-16 18:34 7% ` Juan Manuel Macías
2021-07-17 12:35 4% ` Maxim Nikulin
2021-07-17 14:27 7% ` Juan Manuel Macías
2021-07-14 19:29 9% ` Juan Manuel Macías
2021-07-10 18:43 ` Jonathan McHugh
2021-07-10 19:24 9% ` Juan Manuel Macías
2021-07-26 9:25 7% Multilingual quotes inside paragraphs Juan Manuel Macías
2021-07-28 12:13 5% ` Maxim Nikulin
2021-07-28 13:49 8% ` Juan Manuel Macías
2021-08-01 16:02 5% ` Maxim Nikulin
2021-08-01 20:29 TMIO July Post: Introducing Citations Timothy
2021-08-02 7:23 10% ` Juan Manuel Macías
2021-08-03 10:47 10% [PATCH] ox.el: fix spanish translation for `footnotes' Juan Manuel Macías
2021-08-07 20:10 6% ` Nicolas Goaziou
2021-08-04 16:01 ConTeXt exporter for Org Mode Jason Ross
2021-08-04 19:43 10% ` Juan Manuel Macías
2021-08-05 10:23 6% ` András Simonyi
2021-08-06 10:33 9% "Continuous Integration and TeX with Org-Mode", by Rohit Goswani (TUG 2021) Juan Manuel Macías
2021-08-13 13:45 8% [tip] get the verse number at point inside a verse block Juan Manuel Macías
2021-08-13 14:17 return column from table as a column Roger Mason
2021-08-13 14:47 10% ` Juan Manuel Macías
2021-08-13 16:32 6% ` Roger Mason
2021-08-13 17:12 10% ` Juan Manuel Macías
2021-08-14 10:30 6% ` Roger Mason
2021-08-13 18:40 Org + git branches for derived files Ken Mankoff
2021-08-13 20:53 10% ` Juan Manuel Macías
2021-08-13 22:29 Custom function for killing the thing at point Rodrigo Morales
2021-08-13 22:46 10% ` Juan Manuel Macías
2021-08-14 15:06 7% Smart quotes for Greek (questions for a possible patch) Juan Manuel Macías
2021-08-15 15:59 5% ` Maxim Nikulin
2021-08-15 21:28 6% ` mvar
2021-08-16 13:57 8% ` Juan Manuel Macías
2021-08-27 16:23 3% ` Protesilaos Stavrou
2021-08-31 11:11 9% ` Juan Manuel Macías
2021-08-19 11:04 8% Search in descriptive plain lists Juan Manuel Macías
2021-08-26 13:43 how to get multi-line author in ODT export? Eric S Fraga
2021-08-26 14:24 ` Eric S Fraga
2021-08-26 16:05 10% ` Juan Manuel Macías
2021-08-26 16:54 13% ` Juan Manuel Macías
2021-08-26 18:34 6% ` John Kitchin
2021-08-27 1:46 10% ` Juan Manuel Macías
2021-08-27 13:29 pygments support Yuchen Pei
2021-08-27 13:49 10% ` Juan Manuel Macías
2021-09-02 0:42 Support for tabularray in LaTeX export Vikas Rawal
2021-09-02 8:36 8% ` Juan Manuel Macías
2021-09-02 10:08 7% ` Vikas Rawal
2021-09-16 21:40 [PATCH] Fix some typos Stefan Kangas
2021-09-17 9:03 ` Timothy
2021-09-17 10:05 ` Marco Wahl
2021-09-22 16:47 ` Max Nikulin
2021-09-22 20:18 10% ` Juan Manuel Macías
2021-09-23 14:49 6% ` Max Nikulin
2021-09-24 6:03 0% ` Loris Bennett
2021-09-24 12:23 7% ` Juan Manuel Macías
2021-09-25 11:08 6% ` Marco Wahl
2021-09-25 11:47 6% ` [PATCH] org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and another, typo Max Nikulin
2021-09-18 8:14 Overlining troubles Ypo
2021-09-18 12:50 5% ` Max Nikulin
[not found] <mailman.33.1631980810.21752.emacs-orgmode@gnu.org>
2021-09-18 17:14 0% ` Ypo
2021-09-18 17:32 ` Timothy
2021-09-18 17:51 0% ` Ypo
2021-09-19 16:30 9% [PATCH] ox.el: add smart quotes for Greek Juan Manuel Macías
2021-09-20 14:54 4% ` Max Nikulin
2021-09-21 20:20 8% ` Juan Manuel Macías
2021-09-22 17:19 5% ` Max Nikulin
2021-09-22 19:55 8% ` Juan Manuel Macías
2021-09-23 16:10 6% ` Max Nikulin
2021-09-23 17:17 8% ` Juan Manuel Macías
2021-09-25 19:56 7% ` Juan Manuel Macías
2021-09-22 6:26 [ANN] org-ql 0.6 released Adam Porter
2021-09-22 12:10 10% ` Juan Manuel Macías
2021-09-22 22:41 6% ` Adam Porter
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).