Re: [PATCH] Re: Concatenate properties
Ihor Radchenko writes:
> Note that your patch is >15LOC long and you need to sign the copyright
> agreement with FSF in order to contribute. See
> https://orgmode.org/worg/org-contribute.html#copyright
I've already submitted a copyright assignment to the FSF in order to
publish on ELPA. Do I need one specific to org-mode?
> Some comments on the patch:
>
>> * lisp/org.el (org-property-separators, org-property-get-separator):
>> Created.
>
> I'd make the function private: org--property-get-separator. It is not
> intended as an API function.
I agree, that was an oversight.
>
>> (org-entry-get, org-entry-get-with-inheritance): Use new
>> org-property-get-separator function.
>
>> org-property-separators is a customization option that allows for
>
> Please quote the function name as `org-property-get-separator'.
>
No problem.
>> +If a property is specified multiple times with a =+=, like
>> +=:EXPORT_FILE_NAME+:=, the old behavior was to always combine them
>> +with a single space. For the new variable, the car of each item in
>> the
>
> Please, use double space " " to separate sentences. Also, see
> doc/Documentation_Standards.org
No problem.
>
>> +For example, in order to combine =EXPORT_FILE_NAME= properties with a
>> +forward slash =/=, one can use
>> +
>> +#+begin_src emacs-lisp
>> +(setq org-use-property-inheritance '("EXPORT_FILE_NAME")
>> + org-property-separators '((("EXPORT_FILE_NAME") . "/")))
>> +#+end_src
>
> This example is a bit confusing because it is unclear what you want to
> achieve and why you also need to set inheritance.
Inheritance is the most likely scenario one would need to use the '+'
property syntax, but I do agree it's kinda distracting and not
absolutely necessary in order to get the correct behavior.
>
>> +(defcustom org-property-separators nil
>> ...
>> + :group 'org-properties
>> + :type '(alist :key-type string :value-type sexp))
>
> This defcustom type does not match what you described in the docstring.
> You need something like :type '(alist :key-type (choice string (repeat
> string)) :value-type string)
>
> Best,
> Ihor
Setting ':value-type string' is confusing, in my opinion, because the
default single space looks like: in the customization buffer, which is
indistinguishable from no space: . I just found out about the restricted-sexp
type, which I think makes the customization buffer more user-friendly.
>From f474cb25840fdc6b24618b1452cb7fdd32545092 Mon Sep 17 00:00:00 2001
From: Tyler Grinn
Date: Mon, 9 May 2022 15:52:58 -0400
Subject: [PATCH] lisp/org.el: Add org-property-separators option
* lisp/org.el (org-property-separators, org-property-get-separator):
Created.
(org-entry-get, org-entry-get-with-inheritance): Use new
`org-property-get-separator' function.
* testing/lisp/test-org.el (test-org/entry-get): Added tests for
combining properties with custom separators
`org-property-separators' is a customization option that allows for
properties to be combined using a separator other than the default (a
single space). It is an alist with the car of each element being a
list of property names or regular expression and the cdr being the
separator string, like '((("EXPORT_FILE_NAME") . "/")).
---
etc/ORG-NEWS | 31 ++
lisp/org.el | 47 +---
testing/lisp/test-org.el | 30 -
3 files changed, 99 insertions(+), 9 deletions(-)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 27de6da62..9d1d2cdcf 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -141,6 +141,37 @@ discouraged when working with Org files.
** New features
+*** New customization option =org-property-separators=
+A new alist variable to control how properties are combined.
+
+If a property is specified multiple times with a =+=, like
+
+#+begin_src org
+:PROPERTIES:
+:EXPORT_FILE_NAME: some/path
+:EXPORT_FILE_NAME+: to/file
+:END:
+#+end_src
+
+the old behavior was to always combine them with a single space
+(=some/path to/file=). For the new variable, the car of each item in
+the alist should be either a list of property names or a regular
+expression, while the cdr should be the separator to use when
+combining that property.
+
+The default value for the separator is a single space, if none of the
+provided items in the alist match a given property.
+
+For example, in order to combine =EXPORT_FILE_NAME= properties with a
+forward slash =/=, one can use
+
+#+begin_src emacs-lisp
+(setq org-property-separators '((("EXPORT_FILE_NAME") . "/")))
+#+end_src
+
+The example above would then produce the property value
+=some/path/to/file=.
+
*** New library =org-persist.el= implements variable persistence across Emacs sessions
The library stores variable data in ~org-persist-directory~ (set to XDG
diff --git a/lisp/org.el b/lisp/org.el
index cab59b87c..643fd6b73 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -2850,6 +2850,34 @@ in this variable)."
(member-ignore-case property
Re: [PATCH] org-macs.el: Do not compare wall time and file modification time
On 5/12/22 09:55, Max Nikulin wrote: +(unless (file-exists-p file) + (error "File to tangle does not exist: %s" file)) +(when (file-newer-than-file-p file tangled-file) (org-babel-tangle-file file ... file-newer-than-file-p succeeds only if FILE exists, so in that case it'd be a bit more efficient to avoid testing FILE's existence again, e.g.: (cond ((file-newer-than-file-p file tangled-file) (org-bable-tangle-file file ...)) ((not (file-exists-p file)) (error "File to tangle does not exist: %s" file)))
Re: Org-cite/Citar cannot recognize neither biblatex nor natbib
Hi Bruce, thank you for your help. Indeed, loading both functionalities (require 'oc-biblatex) (require 'oc-natbib) did the trick. That's strange, though: my version of Org (get from M-x org-version) is Org mode version 9.5.3 (9.5.3-g69c588 @ /home/alessandro/.emacs.d/elpa/org-9.5.3/). Shouldn't it already be fixed? Moreover, I now encounter a different problem: biblatex works great, but natbib doesn't. It's not a big problem, since I use biblatex, but here it is, if someone is interested. If I set up natbib as reference engine (with #+cite_export: natbib kluwer), and I export to a pdf file (C-c C-e l o) the references are not resolved, i.e. they are shown as "(?)". However, if I export to a LaTeX file (C-c C-e l l), and then compile it, everyting is fine (although it displays some annoing "n.d."). After that, if I try again to directly export to pdf, it works. I suppose it's a problem in producing the intermediate bibliography files. Alessandro
Re: Org-cite/Citar cannot recognize neither biblatex nor natbib
On Thu, May 12, 2022 at 2:31 PM Alessandro Bertulli wrote: > > Hi Bruce, > thank you for your help. Indeed, loading both functionalities > (require 'oc-biblatex) > (require 'oc-natbib) > did the trick. That's strange, though: my version of Org (get from M-x > org-version) is Org mode version 9.5.3 (9.5.3-g69c588 @ > /home/alessandro/.emacs.d/elpa/org-9.5.3/). Shouldn't it already be > fixed? IDK; my version is newer: Org mode version 9.6 (9.6-??-2bd34edb64 @ /home/bruce/.config/emacs/.local/straight/build-29.0.50/org/) I'm using doom, which as you can tell is using straight. Bruce
Re: How to stop results being hidden when using ":results drawer"?
>> I’m creating documents where I run Python code blocks that create LaTeX >> mathematical output that I want to be able to export to either LaTeX/PDF or >> HTML. >> >> Using :wrap in the header works fine, except that LaTeX complains about the >> unknown environment “results” (it still compiles the file to PDF fine). >> >> Using :wrap export latex works fine for LaTeX export, but I can’t get HTML >> that way. >> >> The recommended method seems to be to use :results drawer. This works fine >> from an export perspective to both LaTeX/PDF and to HTML. However, it has >> one significant drawback when I’m actually creating the document: the >> results drawer starts out hidden and to see what’s there I have to click on >> it. This makes debugging the code in the first place a lot less convenient. >> >> Is there a way to use :results drawer and have the results NOT hidden by >> default? > > I think that you are experiencing the same issue with > https://list.orgmode.org/80k0ar1lml@felesatra.moe/T/#u > > Does it help when you run > M-: (setq org-fold-core-first-unfold-functionsp nil) > before running the code block? > > Best, > Ihor Thanks for the suggestion, Ihor, but like John, this doesn’t solve my problem. For now, I'm using :wrap flushleft, which allows exporting to both LaTeX and HTML without errors, allows xenops to preview my LaTeX output, and doesn’t have any hiding issues. I’ve also reported the issue to the author of xenops.
Re: [PATCH] org-macs.el: Do not compare wall time and file modification time
On 11/05/2022 23:24, Paul Eggert wrote: The comments don't seem to match the code here. + (let* ((tangled-file (concat (file-name-sans-extension file) ".el")) + (file-mtime (file-attribute-modification-time + (file-attributes (file-truename file + (tangled-mtime (file-attribute-modification-time + (file-attributes (file-truename tangled-file) + ;; Tangle only if the Elisp file is older than the Org file. + ;; Filesystem may have coarse timestamp resolution (HFS+, FAT) + ;; so no need to update if timestamps are equal and thus + ;; `org-file-newer-than-p' can not be used here. + (unless (and file-mtime + tangled-mtime + (not (time-less-p tangled-mtime file-mtime))) Although this looks correct, there's no need to go to the work of computing file-mtime in the common case where tangled-mtime is nil. Thank you, I missed such case. I discovered that the code below recompiles an .el file even the .elc one is newer, moreover loading of compiled file is broken by another modernization of emacs code (see the dedicated thread). That is why I did not bother if the code may be optimized a bit. Finally I have found `file-newer-than-file-p' that looks suitable for such case. From b2a546e239f32c78fb2dfaf92201a0b23eb76059 Mon Sep 17 00:00:00 2001 From: Max Nikulin Date: Fri, 6 May 2022 23:34:52 +0700 Subject: [PATCH] org-macs.el: Do not compare wall time and file modification time * lisp/org-macs.el (org-file-newer-than-p): Fix Emacs-29 problem with changed representation of system clock timestamp. Recommend passing file modification time and do not truncate its precision. (org-compile-file): Store file modification time instead of system clock for later comparison by `org-file-newer-than-p'. * lisp/org.el (org-babel-load-file): Use `file-newer-than-file-p' instead of `org-file-newer-than-p' since the former is more suitable for target-prerequisite relation in the case of equal timestamps. Improve error reporting when source file does not exist. Unchanged timestamp of a file means failure of `org-compile-file' but in `org-babel-load-file' the target may be considered up to date if its timestamp is equal to the one for prerequisite. So `org-file-newer-than-p' is not suitable for both cases. The difference matter for filesystems with coarse timestamp resolution, for example HFS+. Before "Bad bounding indices: 0, 2" error was signalled in response to call of `org-babel-load-file' for a non-existing .org file. Reported by Mark Barton https://list.orgmode.org/bf5b9308-3fef-4dc6-98c9-bff36f19d...@gmail.com During discussion of the issue Paul Eggert suggested over variants of the changes in the same thread. --- lisp/org-macs.el | 29 ++--- lisp/org.el | 10 +- 2 files changed, 23 insertions(+), 16 deletions(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index b10725bd5..23e005e6f 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -256,16 +256,23 @@ ignored in this case." ;;; File (defun org-file-newer-than-p (file time) - "Non-nil if FILE is newer than TIME. -FILE is a filename, as a string, TIME is a list of integers, as -returned by, e.g., `current-time'." - (and (file-exists-p file) - ;; Only compare times up to whole seconds as some file-systems - ;; (e.g. HFS+) do not retain any finer granularity. As - ;; a consequence, make sure we return non-nil when the two - ;; times are equal. - (not (time-less-p (cl-subseq (nth 5 (file-attributes file)) 0 2) - (cl-subseq time 0 2) + "Non-nil if FILE modification time is greater than TIME. +TIME should be obtained earlier for the same FILE name using + + (file-attribute-modification-time (file-attributes file)) + +If TIME is nil (file did not exist) then any existing FILE +is considered as a newer one. Some file systems have coarse +timestamp resolution, for example 1 second on HFS+ or 2 seconds on FAT, +so nil may be returned when file is updated twice within a short period +of time. File timestamp and system clock `current-time' may have +different resolution, so attempts to compare them may give unexpected +results. + +Consider `file-newer-than-file-p' to check up to date state +in target-prerequisite files relation." + (let ((mtime (file-attribute-modification-time (file-attributes file +(and mtime (or (not time) (time-less-p time mtime) (defun org-compile-file (source process ext err-msg log-buf spec) "Compile a SOURCE file using PROCESS. @@ -299,7 +306,7 @@ it for output." (full-name (file-truename source)) (out-dir (or (file-name-directory source) "./")) (output (expand-file-name (concat base-name "." ext) out-dir)) - (time (current-time)) + (time (file-attribute-modification-time (file-attributes output))) (err-msg (if (stringp err-msg) (concat ". " err-msg) ""))) (save-window-excursion (pcase
Re: [PATCH] (v3) New LaTeX code export option: engraved
Hi Daniel, > Looks good. I had to update `engrave-faces’ to 0.3 because of new > variables/functions and it works now. It does what it says on the box so > let’s move forward introducing these changes and be open to feedback. > > Thank you very much for introducing this feature! That’s great to hear! I’ve just tagged and pushed 0.3.1 of engrave-faces, so HEAD is no longer required, along with my patch of ox-latex commits. Thanks for helping with the process of getting this in, this has been over a year in the works and so it feels fantastic to have this feature in-tree at last! All the best, Timothy
Re: [PATCH] (v3) New LaTeX code export option: engraved
Looks good. I had to update `engrave-faces' to 0.3 because of new variables/functions and it works now. It does what it says on the box so let's move forward introducing these changes and be open to feedback. Thank you very much for introducing this feature! -- Daniel Fleischer
Re: [BUG] org-babel-load-file can not compile file
On 11/05/2022 19:41, Ihor Radchenko wrote: Max Nikulin writes: Actual result: Compiling /home/ubuntu/examples/org/ex-ob-load-file.el...done Wrote /home/ubuntu/examples/org/ex-ob-load-file.elc progn: Cannot open load file: No such file or directory, ex-ob-load-file.el It seems, it is a regression caused by the Org commit 0193b543e9ef84bfefe76d55e330d5b1cb842cef - (byte-compile-file tangled-file 'load) + (byte-compile-file tangled-file) + (load tangled-file) What if you substitute the load call with (load (byte-compile-dest-file tangled-file))? I do not mind (of course if there is no plan to deprecate the function). In addition, from my point of view, `byte-recompile-file' with 0 as the FORCE argument is more suitable than simple `byte-compile-file' since the former does not rewrite the compiled file when it is up to date.
Re: Org-cite/Citar cannot recognize neither biblatex nor natbib
On Thu, May 12, 2022 at 10:48 AM Alessandro Bertulli wrote: > > Hi again. > > After fixing org-ref, I was exploring org-cite and citar. Again, I'm not > sure how to make everything work. When I try to export to a LaTeX pdf > file, I got the error "user-error: Unknown processor natbib", despite > I put the exact header suggested in the manual > (https://orgmode.org/manual/Citation-export-processors.html). > Note that the same happens if I put > #+cite_export: biblatex > in which case of course I get "user-error: Unknown processor biblatex". > > What am I doing wrong this time? It just means org hasn't loaded that export processor. There was a change a few months ago that should correctly autoload processors in these situations. So assuming you're running an older version, you have two options: 1. update your org 2. manually configure the oc-biblatex processor loading using require or use-package Bruce
Re: [BUG] C-u C-u C-u TAB regression on master
> Allen Li writes: > > > There appears to be a regression in the behavior of C-u C-u C-u TAB on > > master (at aea24b3feafb9c389dc5933005928462bb20c4f8). > > > > C-u C-u C-u TAB is supposed to show everything including drawers, but on > > this test file it does not show property drawers: Thanks for reporting this! I was about to create a report for the same issue. For me though, this issue persisted regardless of the value of org-fold-core-style. But it's fixed now. On Thu, May 12, 2022 at 9:43 AM Ihor Radchenko wrote: > Thanks for reporting! > Fixed on main via 7dcd15105. Thanks! I confirm the fix.
Org-cite/Citar cannot recognize neither biblatex nor natbib
Hi again.
After fixing org-ref, I was exploring org-cite and citar. Again, I'm not
sure how to make everything work. When I try to export to a LaTeX pdf
file, I got the error "user-error: Unknown processor natbib", despite
I put the exact header suggested in the manual
(https://orgmode.org/manual/Citation-export-processors.html).
Note that the same happens if I put
#+cite_export: biblatex
in which case of course I get "user-error: Unknown processor biblatex".
What am I doing wrong this time?
My setup:
init.el relevant config -
(require 'citar)
(setq org-cite-global-bibliography '("~/Library/debug.bib"))
(setq org-cite-insert-processor 'citar
org-cite-follow-processor 'citar
org-cite-activate-processor 'citar
citar-bibliography org-cite-global-bibliography)
(define-key org-mode-map (kbd "C-c b") #'org-cite-insert)
(define-key minibuffer-local-map (kbd "M-b") #'citar-insert-preset)
~/Library/debug.bib
@book{acm:code,
title = {{{ACM}} Code of Ethics and Professional Conduct. {{Affirming}} Our
Obbligation to Use Our Skills to Benefit Society},
editor = {{Association for Computing Machinery}},
date = {2018},
doi = {10.1145/3274591},
url =
{https://www.acm.org/binaries/content/assets/about/acm-code-of-ethics-booklet.pdf},
shorteditor = {ACM}
}
@article{acm:teachingethics,
title = {How to Teach Computer Ethics through Science Fiction},
author = {Burton, Emanuelle and Goldsmith, Judy and Mattei, Nicholas},
date = {2018-07},
journaltitle = {Communications of The Acm},
shortjournal = {Commun. ACM},
volume = {61},
number = {8},
pages = {54--64},
publisher = {{Association for Computing Machinery}},
location = {{New York, NY, USA}},
issn = {0001-0782},
doi = {10.1145/3154485},
url = {https://doi.org/10.1145/3154485},
abstract = {Science fiction in particular offers students a way to cultivate
their capacity for moral imagination.},
issue_date = {August 2018},
pagetotal = {11}
}
org-cite.org -
#+title: Org-cite examples
#+bibliography:~/Library/debug.bib
#+cite_export: natbib kluwer
* First section
Some text [cite:@acm:teachingethics]
* Bibliography
#+print_bibliography:
--
Thanks for your help
Re: Org-ref not working when exporting to LaTeX
Thank you professor Kitchin. Our org-LaTeX-pdf-process differ only for the "-f" option, so I don't think that's the cause. However, it turned out that biber was NOT installed with my TeX distribution. After installing it, it all worked well. Sorry if this actually silly error got some headaches. Daniel, thanks for your suggestion. Your advice and professor Kitchin's answer actually questioned me: I know basically nothing about the differences between LaTeX, biblatex and CSL, so I think I need to investigate that before deciding wich one to use. Thanks again, Alessandro Bertulli
Re: [BUG] C-u C-u C-u TAB regression on master
Allen Li writes: > There appears to be a regression in the behavior of C-u C-u C-u TAB on > master (at aea24b3feafb9c389dc5933005928462bb20c4f8). > > C-u C-u C-u TAB is supposed to show everything including drawers, but on > this test file it does not show property drawers: > > This bug does not manifest on small files, e.g. containing one copy of > the above. > > This is using (setq org-fold-core-style 'text-properties), the default. > The behavior does not happen with 'overlays. > > Can anyone else reproduce? Thanks for reporting! Fixed on main via 7dcd15105. Best, Ihor
Re: How to stop results being hidden when using ":results drawer"?
This does not change anything for me. The function that causes folding for me is `org-entry-show'. Presumably because of this line: (org-cycle-hide-drawers 'children) My solution was an override advice that makes this function not run when point is in a src-block (https://github.com/jkitchin/scimax/blob/master/scimax-jupyter.el#L281). Ihor Radchenko writes: > Richard Stanton writes: > >> I’m creating documents where I run Python code blocks that create LaTeX >> mathematical output that I want to be able to export to either LaTeX/PDF or >> HTML. >> >> Using :wrap in the header works fine, except that LaTeX complains about the >> unknown environment “results” (it still compiles the file to PDF fine). >> >> Using :wrap export latex works fine for LaTeX export, but I can’t get HTML >> that way. >> >> The recommended method seems to be to use :results drawer. This works fine >> from an export perspective to both LaTeX/PDF and to HTML. However, it has one >> significant drawback when I’m actually creating the document: the results >> drawer starts out hidden and to see what’s there I have to click on it. This >> makes debugging the code in the first place a lot less convenient. >> >> Is there a way to use :results drawer and have the results NOT hidden by >> default? > > I think that you are experiencing the same issue with > https://list.orgmode.org/80k0ar1lml@felesatra.moe/T/#u > > Does it help when you run > M-: (setq org-fold-core-first-unfold-functionsp nil) > before running the code block? > > Best, > Ihor -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu Pronouns: he/him/his
Re: Regarding arbitrary Org blocks
On Thu, May 12, 2022 at 06:19:35PM +0800, Ihor Radchenko wrote: > > Some recent change instead now says "No special environment to edit > > here". How can I get back that behavior? > > I am unable to get the described behaviour even using Org 8.2.10. Could > you elaborate what you mean by "used to"? Which Org version? It's been quite some time. I've been using Org for years and I don't keep it up to date. I can't identify when it changed, only that my muscle memory started throwing errors. ;] To be fair, I think I only moved to v9 this year. So I may have learned this in versions before v8. > > Could I add some minor mode to say text-mode with auto-fill-mode and > > aspell somewhere when opening those blocks? > > Not currently, unless you advice org-edit-special. Though we might add > something like org-edit-special-hook (similar to org-ctrl-c-ctrl-c-hook) > if others are also interested in this functionality. That's the kind of configuration I was referring to. It'd be fine to me to add items to match the tags I use. On the other hand, perhaps it would be useful to have a fallback behavior to use the current org-mode settings in a popup buffer for a block that has no mode associated with it? -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: citation-style-language: new LaTeX package in TL 2022
On Thu, May 12, 2022 at 7:11 AM Juan Manuel Macías wrote: > I'm not sufficiently familiar (at the moment) with org-cite, but I share > the news here in case this new LaTeX package could have some kind of use > for org-cite export options. I've played with it a bit, and it does look promising. I think whether and where it might fit in org-cite (a feature added to oc-csl, or a new export processor) might depend on how its command options evolve. Right now, it has a single "cite" command. Bruce
citation-style-language: new LaTeX package in TL 2022
Hi all, TeX Live 2022 includes a new LaTeX package for citations, 'citation-style-language', written by Zeping Lee. According to the package description: "[...] The citation-style-language package is aimed to provide another reference formatting method for LaTeX that utilizes the CSL styles. It contains a citation processor implemented in pure Lua (citeproc-lua) which reads bibliographic metadata and performs sorting and formatting on both citations and bibliography according to the selected CSL style. A LaTeX package (citation-style-language.sty) is provided to communicate with the processor." https://ctan.org/pkg/citation-style-language https://github.com/zepinglee/citeproc-lua I'm not sufficiently familiar (at the moment) with org-cite, but I share the news here in case this new LaTeX package could have some kind of use for org-cite export options. Best regards, Juan Manuel
Re: Regarding arbitrary Org blocks
Russell Adams writes: > I used to insert arbitrary blocks like: > > #+BEGIN_IMPORTANT > yadda yadda > #+END_IMPORTANT > > in my documents, and when I hit C-c ' to edit them it would give me a > basic buffer and I could edit the plain text within. > > Some recent change instead now says "No special environment to edit > here". How can I get back that behavior? I am unable to get the described behaviour even using Org 8.2.10. Could you elaborate what you mean by "used to"? Which Org version? > I'm really just editing text blocks for Latex export, and the source > block type triggers some latex formatting. It's not source code > language, just plain text. > > Could I add some minor mode to say text-mode with auto-fill-mode and > aspell somewhere when opening those blocks? Not currently, unless you advice org-edit-special. Though we might add something like org-edit-special-hook (similar to org-ctrl-c-ctrl-c-hook) if others are also interested in this functionality. Best, Ihor
Re: How to stop results being hidden when using ":results drawer"?
Richard Stanton writes: > I’m creating documents where I run Python code blocks that create LaTeX > mathematical output that I want to be able to export to either LaTeX/PDF or > HTML. > > Using :wrap in the header works fine, except that LaTeX complains about the > unknown environment “results” (it still compiles the file to PDF fine). > > Using :wrap export latex works fine for LaTeX export, but I can’t get HTML > that way. > > The recommended method seems to be to use :results drawer. This works fine > from an export perspective to both LaTeX/PDF and to HTML. However, it has one > significant drawback when I’m actually creating the document: the results > drawer starts out hidden and to see what’s there I have to click on it. This > makes debugging the code in the first place a lot less convenient. > > Is there a way to use :results drawer and have the results NOT hidden by > default? I think that you are experiencing the same issue with https://list.orgmode.org/80k0ar1lml@felesatra.moe/T/#u Does it help when you run M-: (setq org-fold-core-first-unfold-functionsp nil) before running the code block? Best, Ihor
Re: [oc] multiple cite_export keywords for multiple export processors?
"Bruce D'Arcus" writes: > OIC; that's the part I was missing. > > So something like this? > > #+bind: org-cite-export-processors ((latex biblatex "verbose")) > > It doesn't seem to work though. Is there something wrong with my syntax? Seems to be alright (except that "verbose" is ignored by oc-biblatex). Note that you need org-export-allow-bind-keywords to be set to t. Otherwise, #+bind keywords are ignored. I tried the following .org file: #+bind: org-cite-export-processors ((latex biblatex "verbose")) #+bibliography: /home/yantar92/Git/Books/References.bib [cite:@brovzek2009soldering] Best, Ihor
Re: [PATCH] Re: org-agenda-clock-report-header
Colin Baxter writes: > > Because your clock tables in Org _files_ have nothing to do with > > agenda. There is no "Agenda clock report mode" when you create an > > ordinary clock report in Org buffers. > > Well now you've really confused me because I wasn't in an agenda buffer, > I had constructed a clock table from a non-agenda org file. > > Could give me a concrete example of where the variable > org-agenda-clock-report-header might be used? When you are in agenda, you can press v R to toggle org-agenda-clockreport-mode: (11.5 Commands in the Agenda Buffer) >> Toggle Clockreport mode. In Clockreport mode, the daily/weekly >> agenda always shows a table with the clocked times for the time >> span and file scope covered by the current agenda view. The >> initial setting for this mode in new agenda buffers can be set with >> the variable ‘org-agenda-start-with-clockreport-mode’. By using a >> prefix argument when toggling this mode (i.e., ‘C-u R’), the clock >> table does not show contributions from entries that are hidden by >> agenda filtering(1). See also the variable >> ‘org-clock-report-include-clocking-task’. Best, Ihor
Re: export to latex: begin_example gets exported to verbatim (
>>> "JMM" == Juan Manuel Macías writes: > Hi Uwe, > Uwe Brauer writes: >> Which gets exported to verbatim not lstlisting as I want > Try adding this: > :wrap lstlisting It does! Thanks! smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Re: Concatenate properties
Tyler Grinn writes:
> OK, what I have now is that if the car of an alist item is a list, exact
> matching will be done for each list item, but if it is a string, it will
> be matched as a regular expression.
Sounds reasonable.
Note that your patch is >15LOC long and you need to sign the copyright
agreement with FSF in order to contribute. See
https://orgmode.org/worg/org-contribute.html#copyright
Some comments on the patch:
> * lisp/org.el (org-property-separators, org-property-get-separator):
> Created.
I'd make the function private: org--property-get-separator. It is not
intended as an API function.
> (org-entry-get, org-entry-get-with-inheritance): Use new
> org-property-get-separator function.
> org-property-separators is a customization option that allows for
Please quote the function name as `org-property-get-separator'.
> +If a property is specified multiple times with a =+=, like
> +=:EXPORT_FILE_NAME+:=, the old behavior was to always combine them
> +with a single space. For the new variable, the car of each item in
> the
Please, use double space " " to separate sentences. Also, see
doc/Documentation_Standards.org
> +For example, in order to combine =EXPORT_FILE_NAME= properties with a
> +forward slash =/=, one can use
> +
> +#+begin_src emacs-lisp
> +(setq org-use-property-inheritance '("EXPORT_FILE_NAME")
> + org-property-separators '((("EXPORT_FILE_NAME") . "/")))
> +#+end_src
This example is a bit confusing because it is unclear what you want to
achieve and why you also need to set inheritance.
> +(defcustom org-property-separators nil
> ...
> + :group 'org-properties
> + :type '(alist :key-type string :value-type sexp))
This defcustom type does not match what you described in the docstring.
You need something like :type '(alist :key-type (choice string (repeat string))
:value-type string)
Best,
Ihor
Re: [PATCH] lisp/org-table.el: Use booktabs on org-table-export
Pride Allman writes: > So basically, the export function is doing the overwrite for user options > but to reduce the number of inconsistency we can't use this patch for only > one such option. > > Now you explained it I can't think of a way to solve it without rewriting > the whole thing. Or maybe I need to read the source code more deeply. > Would it be too much to hope for it to be integrated on the basis that > things like this can be added for other options in other export backend > too? Or somehow introduce the global settings there. As an option, the override arguments can be factored out into defcustoms. Then, you would have an option to deal with the problem you encountered. Another possibility comes from the fact that the overrides are mostly copying the defaults or trying to transfer alternative option names into export options: (list :backend 'latex :latex-default-table-mode 'table ;; <- this is default :latex-tables-centered nil <- this is _not_ default. The current default is t :latex-tables-booktabs (plist-get params :booktabs) <- default is nil :latex-table-scientific-notation nil <- this is also default :latex-default-table-environment <- default is "tabular" but :environment is transferred (or (plist-get params :environment) "tabular")) Then, we can: 1. Remove options directly overriding the defaults 2. Do not assign :latex-tables-booktabs and :latex-default-table-environment unless :booktabs and :environment options are actually provided. Currently, when the latter options are not set by user (via #+attr_latex), they are treated as if the user force-set them to nil (because plist-get does not distinguish (:property nil) and complete absence of :property). I like the second possibility better because it will make table export consistent with the rest of export customisation. The downside is that we can break the existing workflows relying on current behaviour (which is not too much of a big deal though - we can always document this change in ORG-NEWS). The first possibility, on the other hand, will not break the current behaviour. However, it will only help people who manage to find this new customisation. We already have too many customisations. > And considering the answer is no for the previous question; is there a > workaround for this? Something people use? Because having to manually edit > the table everytime I export is a bit too much for me. Yes, there should be a workaround. org-table functions only override global export settings, not file-local and element-local. That is you should be able to set #+bind: org-latex-tables-booktabs org-latex-tables-booktabs. Or #+attr_latex: :booktabs t Of course, it is not very intuitive and relies on internal knowledge of the code. Best, Ihor
Re: export to latex: begin_example gets exported to verbatim (
Hi Uwe, Uwe Brauer writes: > Which gets exported to verbatim not lstlisting as I want Try adding this: :wrap lstlisting (I don't use matlab, but I think that should work). Best regards, Juan Manuel
Re: [PATCH] Re: org-agenda-clock-report-header
> Ihor Radchenko writes: > Colin Baxter writes: >> Unfortunately, I see no difference in my clock tables whether I >> have org-agenda-clock-report-header set to t, nil or something >> like "My-Heading", or if I put :Header: as a tag in the file >> headline that contains the clock table, or if I write :Header t >> in the #+BEGIN: clocktable line. You can see I'm ringing the >> changes in ignorant desperation. I'm pretty stupid so I'm >> obviously missing something fundamental here - but what? > Because your clock tables in Org _files_ have nothing to do with > agenda. There is no "Agenda clock report mode" when you create an > ordinary clock report in Org buffers. Well now you've really confused me because I wasn't in an agenda buffer, I had constructed a clock table from a non-agenda org file. Could give me a concrete example of where the variable org-agenda-clock-report-header might be used? Best wishes,
Re: export to latex: begin_example gets exported to verbatim (
>>> "ESF" == Eric S Fraga writes: > Hi Uwe, > should this line >> #+begin_src matlab :results output src :exports results: exports code :eval >> never-export > not be > #+begin_src matlab :results output :exports both :eval never-export Hm, when I use this and Execute the code I also obtain #+RESULTS: #+begin_example sys = A = x1 x2 x3 x1 1 1 0 x2 0 1 0 x3 0 1 1 #+end_example Which gets exported to verbatim not lstlisting as I want smime.p7s Description: S/MIME cryptographic signature
Re: citation biblatex fullcite
Dear Bruce, "Bruce D'Arcus" writes: > On Wed, May 11, 2022 at 6:43 AM Andreas Leha > wrote: >> >> "Bruce D'Arcus" writes: >> >> > On Tue, May 10, 2022, 11:20 PM Andreas Leha >> > wrote: >> >> >> >> Hi all, >> >> >> >> how can I use the (rather) new citation engine with the biblatex backend >> >> to export to \fullcite ? >> > >> > We should add a style for this that maps to biblatex fullcite and >> > natbib bibentry, and which ultimately would work as well in oc-csl. >> > >> > But in the meantime, you can create a custom one. >> > >> > (add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil)) >> > >> >> Dear Bruce and Dominik, >> >> Thanks for the swift reply! I seem to be missing something: >> >> Debugger entered--Lisp error: (void-variable org-cite-biblatex-styles) >> >> What am I missing? > > That variable was added more recently, after org-cite was merged. > > Perhaps you have an older version? > Thanks. Well, time to update I guess. But that'll have to wait until my current lecture is over. Never change a running system Best, Andreas
Re: source block evaluation in #+DATE line
Dear Eric, Eric S Fraga writes: > On Wednesday, 11 May 2022 at 17:50, Eric S Fraga wrote: >> ⚠️ Caution: External sender >> >> >> On Wednesday, 11 May 2022 at 05:15, Andreas Leha wrote: >>> Thanks for the comments. And sorry for the misleading example. I do not >>> want to use source blocks to insert a date. In fact I want to include >>> the current git commit hash on the title slide. >> >> I do this by: > > [...] which I now realise uses a src block so probably not what you > want/need. On the contrary. This is brilliant! I had not thought getting the full #+DATE line to be generated via a code block. I've adopted your idea to my needs and it works perfectly now. Thanks a lot. Best, Andreas
Re: export to latex: begin_example gets exported to verbatim (
Hi Uwe, should this line > #+begin_src matlab :results output src :exports results: exports code :eval > never-export not be #+begin_src matlab :results output :exports both :eval never-export I.e. I think you have the syntax not quite right. -- : Eric S Fraga, with org release_9.5.3-481-gaea24b in Emacs 29.0.50
Re: export to latex: begin_example gets exported to verbatim (
>>> "UB" == Uwe Brauer writes:
> Hi
> Please consider
> * matlab :results output src :exports results: exports code :eval
> never-export
> #+begin_src matlab :results output src :exports results: exports code :eval
> never-export
> clear all
> A=[1 1 0; 0 1 0; 0 1 1];
> B=[0 1; 1 0; 0 1];
> C=[1 1 1];
> D=0;
> sys=ss(A,B,C,D)
> #+end_src
> #+RESULTS:
> #+begin_example
> sys =
> A =
>x1 x2 x3
>x1 1 1 0
>x2 0 1 0
>x3 0 1 1
> #+end_example
> When I export this to latex, I obtain
> \begin{verbatim}
> sys =
> A =
>x1 x2 x3
>x1 1 1 0
>x2 0 1 0
>x3 0 1 1
> \end{verbatim}
Of course I can always add
#+ATTR_LATEX: :environment lstlisting
After I executed the code, but this is a bit cumbersome
smime.p7s
Description: S/MIME cryptographic signature
export to latex: begin_example gets exported to verbatim (
Hi
Please consider
* matlab :results output src :exports results: exports code :eval never-export
#+begin_src matlab :results output src :exports results: exports code :eval
never-export
clear all
A=[1 1 0; 0 1 0; 0 1 1];
B=[0 1; 1 0; 0 1];
C=[1 1 1];
D=0;
sys=ss(A,B,C,D)
#+end_src
#+RESULTS:
#+begin_example
sys =
A =
x1 x2 x3
x1 1 1 0
x2 0 1 0
x3 0 1 1
#+end_example
When I export this to latex, I obtain
\begin{verbatim}
sys =
A =
x1 x2 x3
x1 1 1 0
x2 0 1 0
x3 0 1 1
\end{verbatim}
But I would prefer
\begin{lstlisting}
sys =
A =
x1 x2 x3
x1 1 1 0
x2 0 1 0
x3 0 1 1
\end{lstlisting}
Any idea how?
Thanks and regards
Uwe Brauer
--
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.
