Re: Export LaTeX command inside figure environment
On 08/05/2022 07:30, Juan Manuel Macías wrote:
Thomas S. Dye writes:
Is there a way to add an arbitrary LaTeX command between
\begin{figure} ... \end{figure} during LaTeX export? I want to end up
with the following snippet, but can't figure out how to slip in
\setfloatalignment{b}. \begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth]{hilbertcurves.pdf}
\caption[Hilbert curves]{\label{fig:orgparagraph1} Hilbert curves of
various degrees \emph{n}.}
\setfloatalignment{b}
\end{figure}
I think the :caption attribute could do the trick (of course everything
must be on one line):
#+ATTR_LaTeX: :caption \caption[Hilbert
curves]{\label{fig:orgparagraph1} Hilbert curves of various degrees
\emph{n}.}\setfloatalignment{b}
Would it work if \setfloatalignment{b} is added before \includegraphics?
From my point of view, it is still a hack due to abusing the :placement
attribute, but it is backend agnostic, so reuses caption for HTML and
relieves requirement of single long line:
#+caption[Hilbert curves]: Hilbert curves of various degrees \(n\)
#+name: orgparagraph1
#+attr_latex: :placement [b]\setfloatalignment{b}
[[file:hilbertcurves.pdf]]
# Local Variables:
# org-latex-prefer-user-labels: t
# End:
P.S. Math and absence of period are intentional. I never used tufte, so
unsure if something besides b is meaningful with \setfloatalignment{b}.
I dropped "ht" to make inconsistency apparent and expecting that when
figures are moved to the end of document, "ht" should be used instead
with removing of \setfloatalignment.
[PATCH] Re: tangle option to not write a file with same contents?
Max Nikulin writes: > On 28/10/2021 11:04, Greg Minshall wrote: >> >> i wonder if it would be reasonable to add an option such that, when >> tangling, `org-babel-tangle` would not write a file with the >> already-existing contents of the target file? >> >> this would be helpful, e.g., for those of us who use make(1)-based work >> flows. > > It was not obvious for me earlier that it should be namely an *option*, > not just change of behavior, since e.g. `org-babel-load-file' relies on > timestamp comparison of the source .org file and the derived .el file. I > am unsure concerning default value of such setting. I agree that it should be the default behaviour. The patch is attached. On SSD, when tangling into ~200 files, the patch speeds up tangling by almost 2x: before 7.6 sec; after 4.4 sec. Best, Ihor >From 68d90e73da17e423220211897ad1e86a4eb2e5a1 Mon Sep 17 00:00:00 2001 Message-Id: <68d90e73da17e423220211897ad1e86a4eb2e5a1.1651984776.git.yanta...@gmail.com> From: Ihor Radchenko Date: Sun, 8 May 2022 12:32:40 +0800 Subject: [PATCH] org-tangle: Do not overwrite when contents does not change * lisp/ob-tangle.el (org-babel-tangle): Do not overwrite existing tangled files if their contents is exactly the same as we are going to write during tangle process. This avoids unneeded disk writes and can speed up tangling significantly when many small files are tangles from a single .org source. An example of performance improvement when tangling an .org file into ~200 files: (benchmark-run 10 (org-babel-tangle)) Before the commit (on SSD): (76.33826743 8 11.551725374) After the commit: (43.628606052 4 5.751274237) --- lisp/ob-tangle.el | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el index 16d938afb..c011bf662 100644 --- a/lisp/ob-tangle.el +++ b/lisp/ob-tangle.el @@ -282,11 +282,17 @@ (defun org-babel-tangle ( arg target-file lang-re) lspecs) (when make-dir (make-directory fnd 'parents)) - ;; erase previous file - (when (file-exists-p file-name) - (delete-file file-name)) - (write-region nil nil file-name) - (mapc (lambda (mode) (set-file-modes file-name mode)) modes) + (unless + (let ((new-contents-hash (buffer-hash))) + (with-temp-buffer + (when (file-exists-p file-name) + (insert-file-contents file-name)) + (equal (buffer-hash) new-contents-hash))) + ;; erase previous file + (when (file-exists-p file-name) + (delete-file file-name)) + (write-region nil nil file-name) + (mapc (lambda (mode) (set-file-modes file-name mode)) modes)) (push file-name path-collector)) (if (equal arg '(4)) (org-babel-tangle-single-block 1 t) -- 2.35.1
Re: Export LaTeX command inside figure environment
Aloha Juan Manuel,
Juan Manuel Macías writes:
Hi, Thomas,
Thomas S. Dye writes:
Is there a way to add an arbitrary LaTeX command between
\begin{figure} ... \end{figure} during LaTeX export? I want to
end up
with the following snippet, but can't figure out how to slip in
\setfloatalignment{b}. \begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth]{hilbertcurves.pdf}
\caption[Hilbert curves]{\label{fig:orgparagraph1} Hilbert
curves of
various degrees \emph{n}.}
\setfloatalignment{b}
\end{figure}
I think the :caption attribute could do the trick (of course
everything
must be on one line):
#+ATTR_LaTeX: :caption \caption[Hilbert
curves]{\label{fig:orgparagraph1} Hilbert curves of various
degrees
\emph{n}.}\setfloatalignment{b}
That works. Thanks!
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
Re: Export LaTeX command inside figure environment
Hi, Thomas,
Thomas S. Dye writes:
> Is there a way to add an arbitrary LaTeX command between
> \begin{figure} ... \end{figure} during LaTeX export? I want to end up
> with the following snippet, but can't figure out how to slip in
> \setfloatalignment{b}. \begin{figure}[htb]
> \centering
> \includegraphics[width=.9\linewidth]{hilbertcurves.pdf}
> \caption[Hilbert curves]{\label{fig:orgparagraph1} Hilbert curves of
> various degrees \emph{n}.}
> \setfloatalignment{b}
> \end{figure}
I think the :caption attribute could do the trick (of course everything
must be on one line):
#+ATTR_LaTeX: :caption \caption[Hilbert
curves]{\label{fig:orgparagraph1} Hilbert curves of various degrees
\emph{n}.}\setfloatalignment{b}
Best regards,
Juan Manuel
Export LaTeX command inside figure environment
Aloha all,
Is there a way to add an arbitrary LaTeX command between
\begin{figure} ... \end{figure} during LaTeX export? I want to
end up with the following snippet, but can't figure out how to
slip in \setfloatalignment{b}.
\begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth]{hilbertcurves.pdf}
\caption[Hilbert curves]{\label{fig:orgparagraph1} Hilbert curves
of various degrees \emph{n}.}
\setfloatalignment{b}
\end{figure}
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Ihor Radchenko writes: > Ignacio Casso writes: > >>> Sounds reasonable. Could you prepare a patch? >>> COMMENT should be inside a shy group and note that there might be an >>> arbitrary number of space after COMMENT string. >> >> Here it is. > > Thanks! Could you also update the org-complex-heading-regexp-format > docstring and make the commit massage conform with > https://orgmode.org/worg/org-contribute.html#commit-messages (also see > https://orgmode.org/list/87ilqz14ys.fsf@localhost)? > > Best, > Ihor Done. I attach the patch: >From 646f2a792dc5c6e6fa3933eb1d06420c86cd53c3 Mon Sep 17 00:00:00 2001 From: Ignacio Date: Fri, 6 May 2022 13:51:14 +0200 Subject: [PATCH] lisp/org.el: match COMMENT in `org-complex-heading-regexp-format' * lisp/org.el (org-set-regexps-and-options): Change `org-complex-heading-regexp-format' initialization so that the regexp it produces also matches a headline if it is commented. --- lisp/org.el | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 1d5fc3903..cab59b87c 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -3846,7 +3846,8 @@ expected to be bound to nil when matching against this regexp.") "Printf format to make regexp to match an exact headline. This regexp will match the headline of any node which has the exact headline text that is put into the format, but may have any -TODO state, priority and tags.") +TODO state, priority, tags, statistics cookies (at the beginning +or end of the headline title), or COMMENT keyword.") (defvar-local org-todo-line-tags-regexp nil "Matches a headline and puts TODO state into group 2 if present. @@ -4213,6 +4214,8 @@ related expressions." "\\(?: +" org-todo-regexp "\\)?" "\\(?: +\\(\\[#.\\]\\)\\)?" "\\(?: +" + ;; Headline might be commented + "\\(?:" org-comment-string " +\\)?" ;; Stats cookies can be stuck to body. "\\(?:\\[[0-9%%/]+\\] *\\)*" "\\(%s\\)" -- 2.25.1
[PATCH] org-attach: Attach current Gnus article parts
Hi all, In the attached patch I add a new command for org-attach: save *all* attachments from the current Gnus article to the current org-attach-dir. (Sorry for repeating the word "attach" so much :-)) NB: 1. If no Gnus article is open, it returns an error message. 2. I've only tested it on Emacs 28. I don't know if it can cause any problems on earlier Emacs/Gnus versions. 3. Although there are several alternatives to Gnus, I have chosen Gnus specifically because it is part of GNU Emacs. 4. I think an option could be added to save only certain types of files (pdf, png, jpg, docx, etc.). Best regards, Juan Manuel >From 03a53680df38300110c2095a98bc1dec8cc7adce Mon Sep 17 00:00:00 2001 From: Juan Manuel Macias Date: Sat, 7 May 2022 16:04:06 +0200 Subject: [PATCH] lisp/org-attach.el: new command to attach Gnus current article parts * (org-attach-gnus-save-parts-current-article): Attach current Gnus article parts * (org-attach-commands): add a new key --- lisp/org-attach.el | 17 + 1 file changed, 17 insertions(+) diff --git a/lisp/org-attach.el b/lisp/org-attach.el index 5ee2b84b2..54c8a2bdb 100644 --- a/lisp/org-attach.el +++ b/lisp/org-attach.el @@ -206,6 +206,8 @@ git-functionality from this file.") "Attach a file using symbolic-link method.") ((?u ?\C-u) org-attach-url "Attach a file from URL (downloading it).") +((?g ?\C-g) org-attach-gnus-save-parts-current-article + "Attach current Gnus article parts") ((?b) org-attach-buffer "Select a buffer and attach its contents to the task.") ((?n ?\C-n) org-attach-new @@ -488,6 +490,21 @@ DIR-property exists (that is different from the unset one)." (let ((org-attach-method 'url)) (org-attach-attach url))) +(defun org-attach-gnus-save-parts-current-article () + "Attach current Gnus article parts." + (interactive) + (let* ((attach-dir (org-attach-dir 'get-create)) + (art gnus-article-current) + (subject (gnus-summary-article-subject (cdr art +(if (not art) + (error "There is no open article") + (if (yes-or-no-p (format "Attach current article: \"%s\"" subject)) + (progn + (org-attach-tag) + (gnus-summary-save-parts "." attach-dir art) + (message "New attachment: \"%s\"" subject)) + (keyboard-quit) + (defun org-attach-buffer (buffer-name) "Attach BUFFER-NAME's contents to current outline node. BUFFER-NAME is a string. Signals a `file-already-exists' error -- 2.36.0
Re: Concatenate properties
John Kitchin writes: > Where did you add that? > > 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 Fri, May 6, 2022 at 11:40 AM Tyler Grinn > wrote: > > Thanks for the advice. I've added the caret symbol > (:EXPORT_FILE_NAME^: > assignment-1) to mean 'concatenate' as opposed to + for 'joining'. > If > this is something the community would want I will clean it up and > send > in a patch. I modified 'org--property-local-values' to return a cons list with the car being the value of the property and the cdr being either 'concat or 'join. ;; Find additional values. (let* ((property-extension (org-re-property (concat (regexp-quote property) "[+^]") t t))) (while (re-search-forward property-extension end t) (push (cons (match-string-no-properties 3) (if (string-match-p "\\^\\'" (match-string-no-properties 2)) 'concat 'join)) value))) I used a single re-search in order to maintain the ordering of properties, ie: :PROP: he :PROP^: llo :PROP+: world produces 'hello world' I then updated both 'org-entry-get' and 'org-entry-get-with-inheritance' to 'cl-reduce' the cons list into the final string value.
Re: Concatenate properties
Where did you add that? 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 Fri, May 6, 2022 at 11:40 AM Tyler Grinn wrote: > John Kitchin writes: > > > I believe this is hard coded in org-entry-get-with-inheritance. The > > fastest option would be an override advice with your own function that > > replaces (and value " ") with (and value ""), and maybe the two other > > " " with "". > > > > 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 > > > > Thanks for the advice. I've added the caret symbol (:EXPORT_FILE_NAME^: > assignment-1) to mean 'concatenate' as opposed to + for 'joining'. If > this is something the community would want I will clean it up and send > in a patch. >
Re: Concatenate properties
John Kitchin writes: > I like the variable idea. I would make it a concatenation string for > joining. That way “” would concatenate the way Tyler wants, “ “ would > preserve current behavior, and “,” could lead to a comma separated > list for example. Other things like “\n” might lead to a column, etc. I'm not a huge fan of the variable idea because it would make it impossible to include both behaviors in a single file, whereas extending the syntax maintains any existing properties that used '+'.
Re: [PATCH] update ob-scheme to latest changes in geiser package
Ihor Radchenko writes:
>
> Thanks! Since Felipe has no objections, your patch should be good to apply.
>
> Could you kindly add the geiser version info as a comment inside code?
> Commit message is an unlikely place to be checked regularly and be
> noticed as geiser is updated in future.
>
> Comments are generally preferred over commit messages:
>
> https://orgmode.org/worg/org-contribute.html#commit-messages ->
> -> https://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE
>>> - Explaining the rationale for a design choice is best done in comments
>>> in the source code. However, sometimes it is useful to describe just
>>> the rationale for a change; that can be done in the commit message
>>> between the summary line and the file entries.
>
> Best,
> Ihor
Hello Ihor,
thank you for pointing that out, seems I botched my reading comprehension skill
check.
I have updated the patch and enclosed it, feel free to drop a line if you
notice anything else obviously missing.
Vale,
- Tim
From 3b4120d5b3fb41d4b0a5bbdee4cc7a3f4cd02642 Mon Sep 17 00:00:00 2001
From: Tim Van den Langenbergh
Date: Sat, 23 Apr 2022 14:57:27 +0200
Subject: [PATCH] lisp/ob-scheme.el: Use synchronous eval.
* ob-scheme.el (org-babel-scheme-execute-with-geiser): If available,
use the synchronous `geiser-eval-region/wait' function to get the
evaluation result.
Works with geiser 0.18 (before introduction of async evaluation) and
geiser 0.22 (which introduces `geiser-eval-region/wait').
Modified from a patch proposal by Felipe Lema.
TINYCHANGE
---
lisp/ob-scheme.el | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lisp/ob-scheme.el b/lisp/ob-scheme.el
index 72d2e029e..b91c368a7 100644
--- a/lisp/ob-scheme.el
+++ b/lisp/ob-scheme.el
@@ -55,6 +55,8 @@
(declare-function geiser-mode "ext:geiser-mode" ())
(declare-function geiser-eval-region "ext:geiser-mode"
(start end and-go raw nomsg))
+(declare-function geiser-eval-region/wait "ext:geiser-mode"
+ (start end timeout))
(declare-function geiser-repl-exit "ext:geiser-repl" ( arg))
(declare-function geiser-eval--retort-output "ext:geiser-eval" (ret))
(declare-function geiser-eval--retort-result-str "ext:geiser-eval" (ret prefix))
@@ -176,7 +178,13 @@ is true; otherwise returns the last value."
(setq geiser-impl--implementation nil)
(let ((geiser-debug-jump-to-debug-p nil)
(geiser-debug-show-debug-p nil))
- (let ((ret (geiser-eval-region (point-min) (point-max
+;; `geiser-eval-region/wait' was introduced to await the
+;; result of async evaluation in geiser version 0.22.
+ (let ((ret (funcall (if (fboundp 'geiser-eval-region/wait)
+#'geiser-eval-region/wait
+ #'geiser-eval-region)
+(point-min)
+(point-max
(setq result (if output
(or (geiser-eval--retort-output ret)
"Geiser Interpreter produced no output")
--
2.36.0
Re: #4 Org mode profiling meetup on Sat, May 7
Ihor Radchenko writes: > The time will be the same: 9pm SG time (4pm Kyiv; 2pm London; 9am New > York). Sat, May 7 > > I will post the link to the meeting one hour before the meeting start. Meeting link: https://teamjoin.de/Org-dev-profiling-20220507-d708k Best, Ihor
Re: Concatenate properties
I like the variable idea. I would make it a concatenation string for joining. That way “” would concatenate the way Tyler wants, “ “ would preserve current behavior, and “,” could lead to a comma separated list for example. Other things like “\n” might lead to a column, etc. On Sat, May 7, 2022 at 1:32 AM Ihor Radchenko wrote: > Tyler Grinn writes: > > > Thanks for the advice. I've added the caret symbol (:EXPORT_FILE_NAME^: > > assignment-1) to mean 'concatenate' as opposed to + for 'joining'. If > > this is something the community would want I will clean it up and send > > in a patch. > > Hmm. I am not sure if it going to be a straightforward patch. You may > need to update org-element parser accordingly. > > Also, I do not like the idea of extending org syntax with :PROPERTY^:. > It may be easier to introduce a variable similar to > org-use-property-inheritance where the user can customise how to > accumulate parent properties. > > Best, > Ihor > -- 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
Re: [PATCH] New LaTeX code export option: engraved
Hi Timothy, Very nice set of patches, it looks good. Listings and minted are still workable options and your new engrave library is available. I must admit it's not clear how to customize faces since engrave is a bridge between major modes choices and latex but maybe show one or two examples (say elisp and python) of how to change/override some face. I think next we should apply these patches and be open to feedback about source code latex export using these new changes. I also wish there was a bit more documentation, but we can add more with time. Maybe some feedback from Nicolas G.? Best, -- Daniel Fleischer
Re: [PATCH] New LaTeX code export option: engraved
Ooops, a paren error managed to slip in there.
Here’s a new set, with a little extra refactoring slipped in.
–
Timothy
>From d231437e2c9f96bf70520d9ddda810a95667fcdd Mon Sep 17 00:00:00 2001
From: TEC
Date: Sun, 21 Nov 2021 14:35:34 +0800
Subject: [PATCH 1/7] ox-latex: Refactor `org-latex-src-block'
* lisp/ox-latex.el (org-latex-src-block): Extract the per-format logic
from `org-latex-src-block' into new dedicated functions:
+ `org-latex-src-block--verbatim'
+ `org-latex-src-block--custom'
+ `org-latex-src-block--minted'
+ `org-latex-src-block--listings'
This makes `org-latex-src-block' much less monolithic, taking it from
175 lines to 30, and I find also makes it easier to understand.
---
lisp/ox-latex.el | 339 ++-
1 file changed, 185 insertions(+), 154 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 841ad48bc..c2f728a1c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2997,164 +2997,195 @@ (defun org-latex-src-block (src-block _contents info)
(float (plist-get attributes :float))
(listings (plist-get info :latex-listings)))
(cond
- ;; Case 1. No source fontification.
((or (not lang) (not listings))
- (let ((caption-str (org-latex--caption/label-string src-block info))
- (verbatim (format "\\begin{verbatim}\n%s\\end{verbatim}"
-(org-export-format-code-default src-block info
- (cond ((string= "multicolumn" float)
- (format "\\begin{figure*}[%s]\n%s%s\n%s\\end{figure*}"
- (plist-get info :latex-default-figure-position)
- (if caption-above-p caption-str "")
- verbatim
- (if caption-above-p "" caption-str)))
-(caption (concat
- (if caption-above-p caption-str "")
- verbatim
- (if caption-above-p "" (concat "\n" caption-str
-(t verbatim
- ;; Case 2. Custom environment.
+(org-latex-src-block--verbatim src-block info lang caption caption-above-p label
+ num-start retain-labels attributes float))
(custom-env
- (let ((caption-str (org-latex--caption/label-string src-block info))
- (formatted-src (org-export-format-code-default src-block info)))
- (if (string-match-p "\\`[a-zA-Z0-9]+\\'" custom-env)
- (format "\\begin{%s}\n%s\\end{%s}\n"
- custom-env
- (concat (and caption-above-p caption-str)
- formatted-src
- (and (not caption-above-p) caption-str))
- custom-env)
- (format-spec custom-env
- `((?s . ,formatted-src)
- (?c . ,caption)
- (?f . ,float)
- (?l . ,(org-latex--label src-block info))
- (?o . ,(or (plist-get attributes :options) "")))
- ;; Case 3. Use minted package.
+(org-latex-src-block--custom src-block info lang caption caption-above-p label
+ num-start retain-labels attributes float custom-env))
((eq listings 'minted)
- (let* ((caption-str (org-latex--caption/label-string src-block info))
- (placement (or (org-unbracket-string "[" "]" (plist-get attributes :placement))
- (plist-get info :latex-default-figure-position)))
- (float-env
- (cond
- ((string= "multicolumn" float)
- (format "\\begin{listing*}[%s]\n%s%%s\n%s\\end{listing*}"
- placement
- (if caption-above-p caption-str "")
- (if caption-above-p "" caption-str)))
- (caption
- (format "\\begin{listing}[%s]\n%s%%s\n%s\\end{listing}"
- placement
- (if caption-above-p caption-str "")
- (if caption-above-p "" caption-str)))
- ((string= "t" float)
- (concat (format "\\begin{listing}[%s]\n"
- placement)
- "%s\n\\end{listing}"))
- (t "%s")))
- (options (plist-get info :latex-minted-options))
- (body
- (format
- "\\begin{minted}[%s]{%s}\n%s\\end{minted}"
- ;; Options.
- (concat
- (org-latex--make-option-string
- (if (or (not num-start) (assoc "linenos" options))
- options
- (append
- `(("linenos")
- ("firstnumber" ,(number-to-string (1+ num-start
- options)))
- (let ((local-options (plist-get attributes :options)))
- (and local-options (concat "," local-options
- ;; Language.
- (or (cadr (assq (intern lang)
- (plist-get info :latex-minted-langs)))
- (downcase lang))
- ;; Source code.
- (let* ((code-info (org-export-unravel-code src-block))
- (max-width
- (apply 'max
-(mapcar 'length
- (org-split-string (car code-info)
- "\n")
- (org-export-format-code
- (car code-info)
- (lambda (loc _num ref)
- (concat
- loc
- (when ref
- ;; Ensure references are flushed to the right,
- ;; separated with 6 spaces from the widest line
-
Re: org-fold documentation
On Saturday, 7 May 2022 at 14:55, Vikas Rawal wrote: > I am not sure I understand fully, but are you suggesting that the > problem is because I forgot to compile org and therefore these files > were being compiled during runtime? Would running "make" solve it > then? I have done that anyway since I was not sure if I did it > earlier. Native compilation happens during runtime (i.e. when you are using Emacs) for any .elc files loaded during use that are newer than an existing .eln file or if the .eln file does not already exist. -- : Eric S Fraga, with org release_9.5.3-472-gd2a459 in Emacs 29.0.50
Re: org-fold documentation
> > These are native-comp warnings. They are not uncommon when > native-compiling Org (not only org-fold.el) and generally harmless. > If you are sufficiently annoyed with them, most of these warnings can be > "fixed" by declaring the missing functions. The functions are available > at runtime, but not during native-compilation. > > I am not sure I understand fully, but are you suggesting that the problem is because I forgot to compile org and therefore these files were being compiled during runtime? Would running "make" solve it then? I have done that anyway since I was not sure if I did it earlier. Thanks, Vikas >
Re: org-fold problems
Hi Ihor, On Saturday, 7 May 2022 at 13:30, Ihor Radchenko wrote: > While you are at the deadline, feel free to switch org-fold-core-style > back to overlays. Thank you. I should have done that (had I thought if it ;-)) but deadline met in any case. Next time. > If you get some time and encounter the described issue, can you try to > run M-: (setq org-fold-core-first-unfold-functions nil) and try > org-reveal again? Okay. I cannot replicate the problem with the file I had problems with yesterday (the file has obviously changed in the meantime) but will do so when/if it arises again. On a related matter, I typically use vc-ediff for comparing the current working copy of a file and the last committed version. This used to expand the file completely (assuming I'm remembering correctly) but now (some?) drawers are not opened so if there are differences inside a drawer, I cannot see them via ediff. Does this make sense? If so, is there something I should customise to have *everything* opened when using ediff? Thanks again, eric -- : Eric S Fraga, with org release_9.5.3-472-gd2a459 in Emacs 29.0.50
Re: How to export to markdown programmatically without the table of contents?
On 02/05/2022 23:52, Marcin Borkowski wrote: On 2022-05-01, at 22:01, Berry, Charles wrote: On May 1, 2022, at 2:20 AM, Marcin Borkowski wrote: I'd like to export a Org-mode formatted string to markdown, but without the table of contents. (org-export-string-as my-string 'md t '(toc nil)) didn't work (the ToC was still there). What am I missing? It does seem odd that BODY-ONLY as `t' gives a toc. With latex it does not regardless of `:with-toc'. : (org-export-string-as my-string 'md t '(:with-toc nil)) Thanks! http://mbork.pl/2021-05-02_Org-mode_to_Markdown_via_the_clipboard The following links posted earlier to this mail list might be interesting for you since they are related to "exporting" of org text to other applications: https://github.com/tecosaur/emacs-everywhere System-wide popup Emacs windows for quick edits https://github.com/jkitchin/ox-clip/ Copy formatted content from org-mode The latter copies HTML, not markdown though.
Re: tangle option to not write a file with same contents?
A couple additional notes for the case that someone will find this thread in future. On 28/10/2021 11:04, Greg Minshall wrote: i wonder if it would be reasonable to add an option such that, when tangling, `org-babel-tangle` would not write a file with the already-existing contents of the target file? this would be helpful, e.g., for those of us who use make(1)-based work flows. It was not obvious for me earlier that it should be namely an *option*, not just change of behavior, since e.g. `org-babel-load-file' relies on timestamp comparison of the source .org file and the derived .el file. I am unsure concerning default value of such setting. It was an issue with `org-file-newer-than-p' that reminded me about this thread. P.S. Timestamp comparison is not always reliable to determine whether prerequisite has not been updated. Earlier python had timestamp of .py file saved in the header of compiled .pyc files, but at some moment they switched to hash. https://peps.python.org/pep-0552/ PEP 552 – Deterministic pycs
Re: org-fold documentation
On 07/05/2022 11:15, Ihor Radchenko wrote: Vikas Rawal writes: After upgrading to 9.5.3, I am getting warnings such as this, which I suspect are due to org-fold.et. Warning (comp): org-fold.el:834:27: Warning: Unused lexical variable `org-hide-macro-markers' Disable showing Disable logging Warning (comp): org.el:76:30: Warning: Package cl is deprecated Disable showing Disable logging Warning (comp): ox.el:79:1: Warning: the function ‘org-back-to-heading’ might not be defined at runtime. Disable showing Disable logging Warning (comp): ox.el:79:1: Warning: the function ‘org-next-visible-heading’ might not be defined at runtime. Disable showing Disable logging Warning (comp): ox.el:79:1: Warning: the function ‘org-at-heading-p’ might not be defined at runtime. Disable showing Disable logging Is org-fold.el documented already? I see that org-fold-core.el has several screens of comments at the top of the file. Is it what you are asking for? Any pointers to what might be causing the above? These are native-comp warnings. They are not uncommon when native-compiling Org (not only org-fold.el) and generally harmless. If you are sufficiently annoyed with them, most of these warnings can be "fixed" by declaring the missing functions. The functions are available at runtime, but not during native-compilation. The org-fold.el file has some `declare-function' forms. Do you mean it is just necessary to declare more names? In c++ to speed-up compiling and to deal with circular dependence for declarations, there are some *_fwd.h header files with forward declarations. Such files are enough to make compiler aware that some word is a class, a type, or a function with arguments of certain types. They do not allow to allocate proper amount of space for an object and to construct it (it is necessary to "#include" full header for such purpose), but while e.g. a pointer is passed in the file to be compiled then nothing more is required. Will it help to create files like org-fwd.el with function declarations to allow other packages (even from org-mode) to use "(require 'org-fwd.el)" instead of adding a lot of `declare-function' forms that must be kept in sync with function definitions? It is easier to notice new warnings introduced by changes when where were no warnings before.
Re: [PATCH] New LaTeX code export option: engraved
Hi Ihor,
Find attached an updated patchset, and comments below :)
Ihor Radchenko writes:
> Maybe “The other two options”? Also, using first/second here is a bit
> confusing because: (1) they are actually 3/4 in the above list; (2)
> engraved is listed last.
Docstring changed.
>> +The second more comprehensive option can be used with,
>
> *can be set with
Changed.
> I feel slightly confused about using the word “package” here. Which one
> refers to LaTeX package and which one to Emacs? I would state “Emacs
> package” explicitly to highlight contrast with “LaTeX package”.
Clarifications added to the docstring.
>> +\\{\\\FancyVerbLine}
>
> I’d like to see a comment on what it does.
Added.
> Same request to provide a comment. Also, what it that % TODO doing
> there? It is confusing.
A comment has been added, and the TODO removed.
> Also, it is unclear what the [breakable,xparse] options to tcolorbox are
> doing there and what will happen if the user removes them.
“breakable” allows the box to be broken across pages, and “xparse” provides
`\DeclareTColorBox'.
> Further, I am wondering what is going to happen if the user happens to
> have tcolorbox without options loaded via org-latex-packages-alist.
They could see: ERROR: LaTeX Error: Option clash for package tcolorbox.
They would need to tweak such a tcolorbox entry to include the options used
here.
>> +There is quite a lot of flexibility in what this preamble can be, as long
>> as it:
>> +- Loads the fvextra package.
>> +- Loads the package xcolor (if it is not already loader elsewhere).
>> +- Defines a \“Code\” environment (note the capital C), which can be
>> + later used to wrap \“Verbatim\” environments (provided by fvextra).
>
> The last point is not very clear. What kind of environment?
Anything that the user wants to do to modify the display of the generated
`Verbatim' environment.
>> +(defun org-latex-generate-engraved-preamble (info syntax-colours-p)
>> + “Generate the preamble to setup engraved code.
>> +The result is constructed from `org-latex-engraved-preamble’ and
>> +`org-latex-engraved-options’.”
>
> This is relying on
>
> (:latex-engraved-options nil nil org-latex-engraved-options)
> (:latex-engraved-preamble nil nil org-latex-engraved-preamble)
>
> If it changes any time in future (e.g. to allow per-file settings), the
> docstring may be overlooked.
Docstring tweaked.
> I’d use FIRST-MATCH argument for org-element-map. It will be slightly
> faster on large buffers.
Ah nice, I’ll make use of that.
>> - (downcase org-lang)))
>> + (downcase lang)))
>
> I am not sure if this belongs to this patch. Please double check.
Ooops, moved to the correct patch.
>> +(mapcar ’length
>> +(org-split-string (car code-info)
>> + “”)
>
> I am not sure how well it will work with e.g. Chinese characters in comments.
I’ve added a patch replacing `length' with `string-width'
> Maybe the functions could be rewritten using cl-defun with keys and
> and then called via apply on a let-bound arg plist?
Done.
All the best,
Timothy
>From d231437e2c9f96bf70520d9ddda810a95667fcdd Mon Sep 17 00:00:00 2001
From: TEC
Date: Sun, 21 Nov 2021 14:35:34 +0800
Subject: [PATCH 1/7] ox-latex: Refactor `org-latex-src-block'
* lisp/ox-latex.el (org-latex-src-block): Extract the per-format logic
from `org-latex-src-block' into new dedicated functions:
+ `org-latex-src-block--verbatim'
+ `org-latex-src-block--custom'
+ `org-latex-src-block--minted'
+ `org-latex-src-block--listings'
This makes `org-latex-src-block' much less monolithic, taking it from
175 lines to 30, and I find also makes it easier to understand.
---
lisp/ox-latex.el | 339 ++-
1 file changed, 185 insertions(+), 154 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 841ad48bc..c2f728a1c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2997,164 +2997,195 @@ (defun org-latex-src-block (src-block _contents info)
(float (plist-get attributes :float))
(listings (plist-get info :latex-listings)))
(cond
- ;; Case 1. No source fontification.
((or (not lang) (not listings))
- (let ((caption-str (org-latex--caption/label-string src-block info))
- (verbatim (format "\\begin{verbatim}\n%s\\end{verbatim}"
-(org-export-format-code-default src-block info
- (cond ((string= "multicolumn" float)
- (format "\\begin{figure*}[%s]\n%s%s\n%s\\end{figure*}"
- (plist-get info :latex-default-figure-position)
- (if caption-above-p caption-str "")
- verbatim
- (if caption-above-p "" caption-str)))
-(caption (concat
- (if caption-above-p
Re: Recent changes in org-fold regarding emphasize visibility
Ihor Radchenko [2022-05-07 Sat 12:22] wrote: > Now, we have different kinds of hidden text at hand: > - folded headlines/lists > - folded drawers > - folded blocks > - folded links/emphasis > > The question is what should be the logical behaviour of Org when editing > text inside or at the border of these hidden text types? How should we > interpret the values of org-catch-invisible-edits (nil error show > show-and-error smart)? Hi Ihor, Not sure we need to reinterpret the settings; roughly they cover the different options of what to do when you edit a hidden text: edit anyways, throw an error, unfold but do nothing, unfold and do what you wanted to do and the only thing I don't have an intuition about is the smart option. BTW, there are no issues when the folding core style is "overlays". So why not follow what happens in that case, even formalize it into tests? Best, -- Daniel Fleischer
