Feature request: Default table alignment variable

2021-08-23 Thread Yas
Hello,

Pardon my inexperience toward requesting features for gnu software and
sorry if this is not the correct mail for this purpose.


I use orgmode, ox and ox-latex to convert org to LaTeX. Tables in Persian
are especially problematic to make. For Persian (or any Right-To-Left
script) is - obviously - written from right to left and
`org-export-table-cell-alignment' (assuming it's the right function I
found) just assumes that if there is no explicit instruction on how to
align table cells then it is definitely a `left' align (it should be right).

I'd very much appreciate a custom like
`org-export-table-default-cell-alignment' which can be `setq-local'-ed for
that matter. (Or even better, org-table-default-cell-alignment for use with
or without the export module.)


I am not entirely sure if this short message captures the whole idea or
not. Pardon me for my poorly detailed request.



P.S: Maybe I'm just thinking too far at this point but this can even be
bound to "#+LANGUAGE: fa" and set automatically once implemented.

P.P.S: I generally think Abjad (Persian/Arabic) LaTeX exports are a hassle
with org at the current state. I know the workarounds and patches that make
the XeTeX produce proper outputs for Persian and Arabic and most of them
are required on every setup and I think they should be implement in the org
itself. If the team is interested I could also share details and small
macros on that front too but since I'm still noob in LISP and development I
cannot make P/Rs as of yet. At the best, I can answer questions and provide
guides on how to do what if I'm asked.


Sincerely,
Yas


[PATCH] org-cite: prevent ' from being an active char in LaTeX export

2021-08-23 Thread Timothy
Hi All,

This is a band-aid over the issue raised in
.

  I’ve come across an issue with the `hanging’ package we’re currently 
using for
  LaTeX exports — it also affects punctuation, and makes `,.’“`?!:;’ active
  characters throughout the entire document. That means a LaTeX snippet 
like:
  f’(x) Will now fail to compile ☹. See…

By just adding the [notquote] option, ’ is no longer an active char, and so
f’(x) no longer breaks documents. Long-term, I still think that getting rid of
all this active char stuff would be a good idea, by switching out hanging for
use of `\parshape' if possible.

All the best,
Timothy
>From ad63eb8f4d7d02c9864d5caded0b4f2ee9f54133 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 23 Aug 2021 18:18:33 +0800
Subject: [PATCH] oc-csl: Prevent ' from being a LaTeX active char

* lisp/oc-csl.el (org-cite-csl-finalizer): The hanging LaTeX package
we're using also affects punctuation and makes `,.'"`?!:;' active
characters throughout the entire document.  That means a LaTeX snippet
like \(f'(x)\) will now make the document fail to compile.
See 
for more information.  Adding the [notquote] option stops \(f'(x)\) from
being an issue.

In time it could be worth looking into replacing the hanging package
with some use of \parshape.
---
 lisp/oc-csl.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index 617bddb7e..36a885641 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -595,7 +595,7 @@ (defun org-cite-csl-finalizer (output _keys _files _style _backend info)
 (goto-char (match-beginning 0))
 (let ((re (rx "\\usepackage" (opt "[" (*? nonl) "]") "{hanging}")))
   (unless (re-search-backward re nil t)
-(insert "\\usepackage{hanging}\n"
+(insert "\\usepackage[notquote]{hanging}\n"
   (buffer-string
 
 
-- 
2.32.0



[PATCH] org-cite: define \citeprocitem for LaTeX export

2021-08-23 Thread Timothy
Hi All,

There’s been a discussion over at citeproc-el about how to make hyperref treat
its references the same way as bib(la)tex references, and to get this to work we
need to add a command definition to the preamble, `\citeprocitem'.

┌
│ \makeatletter
│ 
\newcommand{\citeprocitem}[2]{\hyper@linkstart{cite}{citeproc_bib_item_#1}#2\hyper@linkend}
│ \makeatother
└

See  for more 
information.

All the best,
*Timothy*
>From 0988d1c331b8872a4c4aa1b1ea40aa2f9f668d17 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 23 Aug 2021 18:14:05 +0800
Subject: [PATCH 3/4] oc-csl: Define \citeprocitem for LaTeX export

* lisp/oc-csl.el (org-cite-csl-finalizer): In order for
citeproc-generated references to be treated the same as bib(la)tex
references by hyperref, we need to make use of \hyper@linkstart.
However, this requires \makeatletter and \makeatother, which can only be
used in the preamble.  To allow citeproc-el to use \hyper@linkstart, we
add a command definition in the preamble, \citeprocitem.
---
 lisp/oc-csl.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index 0a057036e..617bddb7e 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -589,6 +589,8 @@ (defun org-cite-csl-finalizer (output _keys _files _style _backend info)
 (with-temp-buffer
   (save-excursion (insert output))
   (when (search-forward "\\begin{document}" nil t)
+;; Ensure that \citeprocitem is defined for citeproc-el
+(insert "\\makeatletter\n\\newcommand{\\citeprocitem}[2]{\\hyper@linkstart{cite}{citeproc_bib_item_#1}#2\\hyper@linkend}\n\\makeatother\n\n")
 ;; Ensure there is a \usepackage{hanging} somewhere or add one.
 (goto-char (match-beginning 0))
 (let ((re (rx "\\usepackage" (opt "[" (*? nonl) "]") "{hanging}")))
-- 
2.32.0



Re: Bug: unexpected behavior of nesting braces when exporting to LaTeX

2021-08-23 Thread Nicolas Goaziou
Hello,

Chlo De  writes:

> I use Org-mode to take notes. I found that when there are nesting braces 
> inside \emph{ }, \textit{ }, etc. the output is unexpected. The following org 
> text
>
> \emph{{n+1}-a}
> \textit{a{b}c}
>
> will be translated as LaTeX expressions
>
> \emph\{\{n+1\}-a\}
> \textit\{a\{b\}c\}
>
> Can this be fixed?

Org only supports a limited part of the LaTeX syntax as raw syntax. This
is not AucTeX mode!

For complex macros (e.g., with nested braces), you need to use dedicated
environments, as pointed out by Jérémie.

Regards,

-- 
Nicolas Goaziou



Re: Bug: File variable no longer on first line when running org-id-get-create [9.4.4 (release_9.4.4 @ /usr/share/emacs/27.2/lisp/org/)]

2021-08-23 Thread Peter Prevos



Ihor Radchenko  writes:


Peter Prevos  writes:


-*- mode: org; ispell-local-dictionary: "nederlands" -*-

It works great, except when I need to add an ID for use in 
Org-Roam using the org-id-get-create function.


To make it work, convert the local-var line into proper 
comment. Just as

you would do in any other source code file:

# -*- mode: org; ispell-local-dictionary: "nederlands" -*-
:PROPERTIES:
:ID:   a60f6a47-9db9-49d6-ac00-307c7a84e43d
:END:

When you just have the line below, it is treated as ordinary 
paragraph

by Org, thus the property drawer is indeed inserted before:

:PROPERTIES:
:ID:   a60f6a47-9db9-49d6-ac00-307c7a84e43d
:END:
-*- mode: org; ispell-local-dictionary: "nederlands" -*-

Best,
Ihor


Thanks Ihor, that makes sense.


--
Dr Peter Prevos
---
peterprevos.com



Re: Bug: org-src-font-lock-fontify-block should be wrapped with save-match-data [9.3.7 (9.3.7-4-gba6ca7-elpaplus @ mixed installation! /mnt/c/Users/toz/Weiterbildung/Soft/Emacs/ and /mnt/c/Users/toz/.

2021-08-23 Thread Timothy
Hi Tobias,

Thanks for your efforts. I have prepared a patch accordingly that wraps
org-src-font-lock-fontify-block’s body with save-match-data (attached).

If I don’t hear anything bad about it in the next few days, I’ll push it :)
Please let me know if my commit message agrees with your understanding of the
issue.

All the best,
Timothy
>From c435fd41428b6eb4f9f7971e73ca0a422006461b Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 23 Aug 2021 15:09:24 +0800
Subject: [PATCH] org-src: Save match data when fontifying src block

* lisp/org-src.el (org-src-font-lock-fontify-block): Since
`org-src-font-lock-fontify-block' modifies match data during
fontification, when called in `org-fontify-meta-lines-and-blocks-1' by
`font-lock-fontify-region' the text property font-lock-multiline is
applied to text from the beginning to the last match.  Since there is a
difference in buffer sizes, the match data is invalid and problematic.
This issue can drastically slow down editing operations in large source
blocks.  This can be avoided simply by wrapping `save-match-data' around
`org-src-font-lock-fontify-block'.

Reported by: "Tobias Zawada" 

---
 lisp/org-src.el | 69 +
 1 file changed, 35 insertions(+), 34 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 4698c6dd2..ce33e1f54 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -586,40 +586,41 @@ (defun org-src-font-lock-fontify-block (lang start end)
   "Fontify code block.
 This function is called by emacs automatic fontification, as long
 as `org-src-fontify-natively' is non-nil."
-  (let ((lang-mode (org-src-get-lang-mode lang)))
-(when (fboundp lang-mode)
-  (let ((string (buffer-substring-no-properties start end))
-	(modified (buffer-modified-p))
-	(org-buffer (current-buffer)))
-	(remove-text-properties start end '(face nil))
-	(with-current-buffer
-	(get-buffer-create
-	 (format " *org-src-fontification:%s*" lang-mode))
-	  (let ((inhibit-modification-hooks nil))
-	(erase-buffer)
-	;; Add string and a final space to ensure property change.
-	(insert string " "))
-	  (unless (eq major-mode lang-mode) (funcall lang-mode))
-	  (org-font-lock-ensure)
-	  (let ((pos (point-min)) next)
-	(while (setq next (next-property-change pos))
-	  ;; Handle additional properties from font-lock, so as to
-	  ;; preserve, e.g., composition.
-	  (dolist (prop (cons 'face font-lock-extra-managed-props))
-		(let ((new-prop (get-text-property pos prop)))
-		  (put-text-property
-		   (+ start (1- pos)) (1- (+ start next)) prop new-prop
-		   org-buffer)))
-	  (setq pos next
-	;; Add Org faces.
-	(let ((src-face (nth 1 (assoc-string lang org-src-block-faces t
-  (when (or (facep src-face) (listp src-face))
-(font-lock-append-text-property start end 'face src-face))
-	  (font-lock-append-text-property start end 'face 'org-block))
-	(add-text-properties
-	 start end
-	 '(font-lock-fontified t fontified t font-lock-multiline t))
-	(set-buffer-modified-p modified)
+  (save-match-data
+(let ((lang-mode (org-src-get-lang-mode lang)))
+  (when (fboundp lang-mode)
+	(let ((string (buffer-substring-no-properties start end))
+	  (modified (buffer-modified-p))
+	  (org-buffer (current-buffer)))
+	  (remove-text-properties start end '(face nil))
+	  (with-current-buffer
+	  (get-buffer-create
+	   (format " *org-src-fontification:%s*" lang-mode))
+	(let ((inhibit-modification-hooks nil))
+	  (erase-buffer)
+	  ;; Add string and a final space to ensure property change.
+	  (insert string " "))
+	(unless (eq major-mode lang-mode) (funcall lang-mode))
+	(org-font-lock-ensure)
+	(let ((pos (point-min)) next)
+	  (while (setq next (next-property-change pos))
+		;; Handle additional properties from font-lock, so as to
+		;; preserve, e.g., composition.
+		(dolist (prop (cons 'face font-lock-extra-managed-props))
+		  (let ((new-prop (get-text-property pos prop)))
+		(put-text-property
+		 (+ start (1- pos)) (1- (+ start next)) prop new-prop
+		 org-buffer)))
+		(setq pos next
+	  ;; Add Org faces.
+	  (let ((src-face (nth 1 (assoc-string lang org-src-block-faces t
+	(when (or (facep src-face) (listp src-face))
+	  (font-lock-append-text-property start end 'face src-face))
+	(font-lock-append-text-property start end 'face 'org-block))
+	  (add-text-properties
+	   start end
+	   '(font-lock-fontified t fontified t font-lock-multiline t))
+	  (set-buffer-modified-p modified))
 
 
 ;;; Escape contents
-- 
2.32.0