Re: [BUG] Markdown export broken without toc and with broken links [9.6 (9.6-??-e9da29b)]
Janek F writes: > With the following configuration (on top of vanilla Doom, but that doesn't > seem to be related), when trying to export to Markdown an org-mode file with > broken links, the export omits all content under headlines: > > (setq org-export-with-toc nil > org-export-with-broken-links 't) > > For Example: > > Test [[id:broken]] > * Headline > This is not exported > > exports to: > > Test > > The position of the broken link does not matter, just that there is one. Fixed on bugfix via 14532ec6a. Thanks for reporting! Best, Ihor
[PATCH] Re: [BUG] org-attach-id-ts-folder-format fails on customized IDs [9.6 (9.6-??-2e9999783)]
Janek F writes: > When setting org-id-method to 'ts or 'org, > org-attach seems to use org-attach-id-ts-folder-format > to create its hierarchy. > > However I tend to customize IDs for important files by hand, > causing any attempt to use org-attach on that file to fail > if the ID is shorter than six characters: > > org-attach-id-ts-folder-format: Args out of range: "ftt", 0, 6 > > This method should be adjusted to handle non-ts-ids just as well, > as org-id-method does not dictate the format of existing ids. Thanks for reporting! Tentative patch is attached. I have added some fallbacks for the default attach folder formatters, so that they can work when the ID does not conform to specific format. This change is somewhat opinionated, so feel free to suggest alternative solutions/fallback options. Best, Ihor >From e004752ba39f0d328645a1f6053ad3ce3b06ac28 Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Sat, 23 Jul 2022 13:13:24 +0800 Subject: [PATCH] org-attach-dir-from-id: Do not rely on ID being over 6 chars long * lisp/org-attach.el (org-attach-id-uuid-folder-format): Fall back to using ID md5 hash when the ID contains 2 chars or less and cannot be split into the "xy/z" path. (org-attach-id-ts-folder-format): Fall back to "unknown/ID" path format when the ID contains less than 7 chars and cannot be split into the "MM/rest" path. Fixes https://orgmode.org/list/KC8PcypJapBpJQtJxM0kX5N7Z0THL2Lq6EQjBMzpw1-vgQf72egZ2JOIlTbPYiqAVD4MdSBhrhBZr2Ykf5DN1mocm1ANvvuKKZShlkgzKYM=@pm.me --- lisp/org-attach.el | 25 + 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/lisp/org-attach.el b/lisp/org-attach.el index 36c21b702..7c72fd7ee 100644 --- a/lisp/org-attach.el +++ b/lisp/org-attach.el @@ -159,19 +159,28 @@ (defcustom org-attach-archive-delete nil (defun org-attach-id-uuid-folder-format (id) "Translate an UUID ID into a folder-path. Default format for how Org translates ID properties to a path for -attachments. Useful if ID is generated with UUID." - (format "%s/%s" - (substring id 0 2) - (substring id 2))) +attachments. Useful if ID is generated with UUID. + +When ID is too short (less than 3 chars), use its md5 hash to create +the path." + (if (< (length id) 3) + (org-attach-id-uuid-folder-format (md5 id)) +(format "%s/%s" + (substring id 0 2) + (substring id 2 (defun org-attach-id-ts-folder-format (id) "Translate an ID based on a timestamp to a folder-path. Useful way of translation if ID is generated based on ISO8601 timestamp. Splits the attachment folder hierarchy into -year-month, the rest." - (format "%s/%s" - (substring id 0 6) - (substring id 6))) +year-month, the rest. + +When ID is too short (less than 7 chars), return \"unknown/ID\"." + (if (< (length id) 7) + (format "unknown/%s" id) +(format "%s/%s" + (substring id 0 6) + (substring id 6 (defcustom org-attach-id-to-path-function-list '(org-attach-id-uuid-folder-format org-attach-id-ts-folder-format) -- 2.35.1
Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
Juan Manuel Macías writes: > Here is a new version of the patch, with the fixes added. Thanks! Considering that the followup discussion deviated from the substance of the patch towards related design issues, I have decided to marge the patch as is. We can decide on handling AUTO staff later - it would be a major change to remove and the details of an alternative are not yet worked out. Applied onto main via 97cfb959d after adding some double spaces between sentences and upcasing the beginning of some sentences. Best, Ihor
Re: [FR] Make :var foo=name-of-src-block assign the source block code instead of currently assigned result of evaluation (was: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments)
Sébastien Miquel writes: > The uses are maybe too niche to warrant the breaking change. A syntax > extension like > : var=block-id[] > seems possible, even though brackets are already overloaded. This sounds better. Using brackets will actually make a lot of sense. Currently, we have roughly the following logic in the :var references: - :var x=reference() will execute the reference and assign the returned value - :var x=reference[] will take the reference text representation, possibly process it according to the parameters, and return the processed text *this only works for tables* - :var x=reference will perform some "default" action depending on the reference type. the action may be "execute" or "get text representation" for source blocks and others correspondingly. Extending reference[...] syntax to all the element types will make things consistent and allow future extensions if we decide to provide "index" syntax for non-tables (code lines, function definitions?) > One alternative is to only allow the syntax inside noweb brackets > instead of generic variable arguments. I assume there'd be much less > breakage. It would also makes sense to allow noweb references instead > of block ids. We'd add support for > : <> > and <> would also insert the contents as a > by-product. This would still be a breaking change. And we will introduce inconsistency between resolving noweb references and resolving :var header args. Moreover, resolving references is currently handled by the same code inside :vars and noweb references. Changing this will complicate the source code as well, IMHO increasing the maintenance burden too much. > Do you have any example of use in mind, beyond my original one ? For example, one may convert .el file commentary to Readme.org: #+name: my-library #+begin_src :tangle my-library.el ;; Commentary: ;; A lot of commentary #+end_src #+begin_src :exports results :var commentary=my-library[] (convert-to-org-headlines commentary) #+end_src Best, Ihor
Re: [PATCH] oc-csl: Add support for sub-bibliographies
András Simonyi writes: > ...of course, I managed to leave a typo in the manual patch, please > ignore the earlier version and consider the attached one. Thanks! Could you please create a dedicated subsection under "15 Citation handling" instead of documenting PRINT_BIBLIOGRAPHY together with export processors? The section should contain a general overview of what PRINT_BIBLIOGRAPHY does and that it can appear multiple times. Then, further sub-sub-section will detail on CSL and LaTeX-based processors. > +The "biblatex" and "csl" export processors support passing additional > +bibliography options through a property list attached to the > +=PRINT_BIBLIOGRAPHY= keyword. E.g., Please use "for example" instead of e.g. Not everyone knows Latin or technical English. Best, Ihor
Re: [BUG] Comment links for tangled source blocks at the file root are broken [9.5.4 (9.5.4-gb3b17c @ /home/user/.emacs.d/straight/build/org/)]
Elias Kueny writes: > There seems to be an issue with using ":comments link" when the source block > is at the root of the org file instead of under a heading. This happens using > emacs -Q. > > A file containing something like this: > #+begin_src elisp :tangle yes :comments link > (message "test") > #+end_src > > tangles to: > ;; [[file:test2.org::+begin_src elisp :tangle yes :comments link][No > heading:1]] > (message "test") > ;; No heading:1 ends here > > I don't think the "+begin_src" part is meant to be here. Then > org-babel-detangle looks for a "* +begin_src elisp :tangle yes :comments > link" heading and fails to detangle. Thanks for reporting! Fixed on bugfix via c779b7aa0. Best, Ihor
Re: org-encode-time bug
Morgan Smith writes:
> I'm using emacs from commit f258f67 (quite recent) and org from commit
> 39005dc (quite recent).
>
> I'm using native compilation and PGTK.
> Debugger entered--Lisp error: (invalid-function org-encode-time)
> org-encode-time((0 0 0 21 7 2022 4 t -14400))
> org-matcher-time("<2022-07-21 Thu 00:00>")
> org-clock-get-table-data(...)
> org-dblock-write:clocktable(...)
> org-update-dblock()
> org-ctrl-c-ctrl-c(nil)
> funcall-interactively(org-ctrl-c-ctrl-c nil)
> command-execute(org-ctrl-c-ctrl-c)
org-encode-time is defined in org-macs.el in the latest Org, but _not_
in built-in Org. What you are seeing is most likely caused by "mixed"
installation of Org when part of Org is loaded from built-in Org
distribution coming from Emacs.
> I was able to reproduce this with 'emacs -Q'
>
> When trying to update a clocktable I get the following backtrace (with a
> little bit removed).
Could you please detail on what you did to load the latest org with
Emacs -Q? Using purely emacs -Q cannot trigger the error simply because
org-encode-time is absent in the built-in Org.
Best,
Ihor
org-encode-time bug
Hello,
I'm using emacs from commit f258f67 (quite recent) and org from commit
39005dc (quite recent).
I'm using native compilation and PGTK.
I was able to reproduce this with 'emacs -Q'
When trying to update a clocktable I get the following backtrace (with a
little bit removed).
Debugger entered--Lisp error: (invalid-function org-encode-time)
org-encode-time((0 0 0 21 7 2022 4 t -14400))
org-matcher-time("<2022-07-21 Thu 00:00>")
org-clock-get-table-data(...)
org-dblock-write:clocktable(...)
org-update-dblock()
org-ctrl-c-ctrl-c(nil)
funcall-interactively(org-ctrl-c-ctrl-c nil)
command-execute(org-ctrl-c-ctrl-c)
When I re-evaluate the defun for `org-matcher-time' everything is happy
again. I'm not sure what the issue is but I assume it's related to
compilation or something.
Thanks,
Morgan
[BUG] Comment links for tangled source blocks at the file root are broken [9.5.4 (9.5.4-gb3b17c @ /home/user/.emacs.d/straight/build/org/)]
Hello, There seems to be an issue with using ":comments link" when the source block is at the root of the org file instead of under a heading. This happens using emacs -Q. A file containing something like this: #+begin_src elisp :tangle yes :comments link (message "test") #+end_src tangles to: ;; [[file:test2.org::+begin_src elisp :tangle yes :comments link][No heading:1]] (message "test") ;; No heading:1 ends here I don't think the "+begin_src" part is meant to be here. Then org-babel-detangle looks for a "* +begin_src elisp :tangle yes :comments link" heading and fails to detangle. Emacs : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.17.4) of 2022-04-09 Package: Org mode version 9.5.4 (9.5.4-gb3b17c) Best regards, Elias
Re: Confused about source code blocks evaluation when exporting
Fraga, Eric writes on Fri 22 Jul 2022 17:09: > On Friday, 22 Jul 2022 at 06:27, alain.coch...@unistra.fr wrote: > > Plus one must revisit the file when changing the value of > > that variable. > > You can reload local variables by hitting C-c C-c on the #+title: line, > for instance. Ah OK; thanks. But it just dawns on me that it is faster to type C-x C-v (provided save-place-mode is enabled) -- EOST (École et Observatoire des Sciences de la Terre) ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr 5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44 F-67084 Strasbourg Cedex, France | [ slot available for rent ]
Re: Publishing a project and selecting files (possibly with tags)
Dear Benoit, this does sound like what I have done for my blog: I write all blog posts as org files in a single directory called "posts" and publish them through org-publish. In each file, I define tags via the =FILETAGS= keyword. Upon publishing, I set =:sitemap-format-entry= in =org-publish-project-alist= to a custom function which creates new org files corresponding to the tags being used in the posts. These org files are then published as well, giving me a sitemap with all posts and a sitemap for each individual tag (with short teaser text). This is not exactly what you asked for and maybe not as straightforward as what you envisioned, but I think that you could customize this approach to fit your use case. The code for my blog is available here: https://gitlab.com/hperrey/hoowl_blog (Please note that I copied it together from various sources back when without always understanding every detail and I am afraid that it shows.) The resulting html you can find here: https://www.hoowl.se Let me know should you have questions concerning the code! Best wishes, Hanno Benoit Bidoggia writes: > Dear list, > > This is my problem: I have a large set of org files (created with > org-roam), which contains all my thoughts on different topics (for > example "work1", "work2", "personal1"...) > > I would like to create different projects (for example "work1", > "work2", "personal1") to be able to publish these files under > different folders (for example "./pub_work1", "./pub_work2", > "./pub_personal1") for which I could define some filters to decide > what goes where. > > The rules should be something likes this: > - nothing is exported, except that > - files with tag "WORK1" are exported in "./pub_work1" > - files with tag "WORK2" are exported in "./pub_work2" > - files with tag "PERSONAL1" are exported in "./pub_personal1" > > I cannot use the file name to filter the files, which seems to exclude > the possibility of using the options ":exclude" and ":include" of > org-publish-project-alist. > > Ideally I would like to use tags (or some descriptors I can include > directly in the org file), but I did not have much success using the > options ":with-tags" or ":select-tags". > > Can this be done? If so, how? > > Thank you very much, best regards. > Benoît -- Hanno Perrey https://hoowl.se
Re: Specify defaults for In Buffer Settings
Fraga, Eric wrote: > It comes with Emacs: ah! thanks! cheers, Greg
Re: Specify defaults for In Buffer Settings
On Friday, 22 Jul 2022 at 19:05, Greg Minshall wrote: > sorry, but what is the autoinsert package? It comes with Emacs: ,[ C-h f auto-insert RET ] | auto-insert is an autoloaded interactive compiled Lisp function in | ‘autoinsert.el’. | | (auto-insert) | | Insert default contents into new files if variable ‘auto-insert’ is non-nil. | Matches the visited file name against the elements of ‘auto-insert-alist’. | | Probably introduced at or before Emacs version 19.30. | ` -- : Eric S Fraga, with org release_9.5.4-557-g3bbbf7 in Emacs 29.0.50
Re: Confused about source code blocks evaluation when exporting
On Friday, 22 Jul 2022 at 06:27, alain.coch...@unistra.fr wrote: > Plus one must revisit the file when changing the value of > that variable. You can reload local variables by hitting C-c C-c on the #+title: line, for instance. -- : Eric S Fraga, with org release_9.5.4-557-g3bbbf7 in Emacs 29.0.50
form-like process for entering rows in an org-mode table?
hi. does anyone have any code, or know of any existing package, that would allow for some sort of form-like (or "transient"-like) interface for adding rows to an org-mode table? in particular, that provides some sort of =completing-read= interface for a given set of choices for a given column, etc. cheers, Greg
[Problem persits] (was: [a kludge])
>>> "UB" == Uwe Brauer writes: >>> "UB" == Uwe Brauer writes: >> Hi >> I attach a file that hopefully explains the problem. >> That file contains 109 heading, each heading has 17 different >> properties when all of them are included in the > It seems that > #+begin_src emacs-lisp :results silent :exports none > (org-update-all-dblocks) > #+end_src Unfortunately this is not true when I add one property more in the columnview and have 680 headings. It seems a capacity problem, somehow. I also checked this with master version db6c229786cc4f0855483145 The problem is still there Not sure who to debug this So I have to run (org-update-all-dblocks) a lot of times to finish the columnview for all entries -- 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. smime.p7s Description: S/MIME cryptographic signature
Re: Specify defaults for In Buffer Settings
Eric, > Have a look at #+SETUP but also consider the autoinsert package. sorry, but what is the autoinsert package? cheers, Greg
Re: ChangeLog.org
>>> "AB" == Arne Babenhauserheide writes: > Uwe Brauer writes: >> So the question is, how to generate this file. Maybe there is a >> ChangeLog--> ChangeLog.org exporter/converter? >> >> https://github.com/johnlepikhin/el-conventional-changelog/blob/master/conventional-changelog.el > I see only 6 calls to git in that file. Maybe the easiest way would be > to port it? Well looking more in the code, it seems that the logic is 1. Commit with commit message 2. Then extract and insert that commit message into a org buffer respecting org syntax This is not what I am looking for. My workflow is, usually, the other way around. 1. I add an entry to the ChangeLog file 2. Then I commit this message gets inserted (this step wouldn't make much sense if ChangeLog file uses org syntax, I admit) But I want an independent ChangeLog file not an extracting from my commit messages. Uwe smime.p7s Description: S/MIME cryptographic signature
Re: numbering src blocks in HTML export
Ihor, > Dear All, may we should provide a normal header arg as an equivalent of > switches? Honestly, this whole switch syntax sounds unnecessary and only > over-complicates things. i'm a fan.
Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
Juan Manuel Macías writes:
> OK, so why not just:
>
> #+latex_header: % NOLANG
>
> ?
Forget this. On second thought, I think that the option you proposed
"#+LaTeX_Header: % \usepackage{babel}" is much better.
(I don't know where my head was and I didn't remember there was a
string-match, so your suggestion is the shortest way. However, the line
would have to be (with arguments):
#+LaTeX_Header: % \usepackage[something]{babel}
or
#+LaTeX_Header: % \usepackage[something]{polyglossia}
or modify the regexp in org-latex-guess-babel/polyglossia-language.
Re: [PATCH] Add make target to ease creating reproducers and testing them
Ihor Radchenko writes: > I propose a new make target: make repro > It will run the commands we already suggest, but without a need to > create minimal file, pass all that arguments to emacs, etc Applied onto main via b713b9afa. Best, Ihor
Re: [PATCH] Re: [9.5.2] [org-keys] [cursor keys with modifiers] ESC missing?
Ihor Radchenko writes: > The fix is attached. Applied onto main via b6098500a. Best, Ihor
Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
Max Nikulin writes: > Form my point of view it is unnecessary magic. Originally #+latex_header > is intended for valid LaTeX code OK, so why not just: #+latex_header: % NOLANG ? I think this has in its favor: a) it is simple and obvious to remember; b) it's a single string, and of course c) it's valid LaTeX code. And it can be easily controlled from org-latex-guess-babel/polyglossia-language with a conditional. Anyway, whatever the choice, I would vote for Org not to load babel or polyglossia by default, and for the default option of the custom variable that handles that globally to be nil. For example, I'm in the group of users that load babel using an external preamble (a .tex or a .sty file or a 'latex-class'), and frankly I don't want to have to add a new line to all my documents to prevent Org from reloading babel for me and return an error on the compilation. Best regards, Juan Manuel
Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
On 21/07/2022 22:39, Juan Manuel Macías wrote:
Max Nikulin writes:
I would vote for a custom variable, at the global level (I agree with
the options you suggest) and at the document level, to economize,
perhaps this would be enough to avoid the code of both babel and
polyglossia:
#+latex_header: NOLANG
Form my point of view it is unnecessary magic. Originally #+latex_header
is intended for valid LaTeX code and "% \usepackage{babel} % disable"
does not make code invalid (being a kind of magic though). If you
consider such cast as too verbose then even
#+options: latex-l10n:nil
might be better. I am unsure if babel or polyglossia are parsed as
strings or as symbols in such context. I am still against a DSL for
"#+options:" to generate complex babel commands in favor of explicit
"#+latex_header:".
On 18/07/2022 23:21, Juan Manuel Macías wrote:
\documentclass[11pt,draft,russian]{article}
\usepackage{babel}
I have realized that it resembles
\documentstyle[russian,epsfig,wrapfig,12pt]{article}
from the previous century and LaTeX-2.09. Due to lack of support in
babel, several alternatives to add Russian language existed and one of
them required the \documentstyle option.
Volunteering to maintain ob-processing.el
Greetings. I see that ob-processing.el has currently no maintainer. I volunteer. All the best, Jarmo
Re: Volunteering to maintain ob-asymptote.el within Org
Greetings Munyoki. Munyoki Kilyungi writes: > Hi Jarmo! > > Jarmo Hurri anaandika: > >> I hereby volunteer to maintain ob-asymptote.el. > > Nice! > >> This file has been moved >> to org-contrib, but I would like it to be brought back into Org itself. >> >> I strongly feel that Asymptote is way too valuable as a scientific tool >> to be dropped out of Org. > Isn't this debatable? Yes, that is a good reason to be involved in these discussions. > TBH, this is the first time I'm hearing about it. I've looked it up, > and indeed it seems to be useful. For some reason, even people who would certainly benefit from Asymptote often have not heard of it. The developers do not really advertise. Asymptote is amazingly powerful and sophisticated. > That said, shouldn't this be in org-contrib? Too many features in a > tool - featurism - may be distracting, in the sense that you focus > more on your tool than work at hand. I do not understand this. Why would supporting a professional-level graphics programming language be distracting someone from their work when using Org? > And that said, to work around this, I reckon that's why (?) we have > org-contrib. You - the end user - install what you want/need. Yes, but whenever we split up support, we raise the threshold for the use of a combination of tools, in this case Org and Asymptote. Org is a very powerful publication tool. Does it not make complete sense to include support for a tool for creating professional-quality publication graphics? All the best, Jarmo
Re: The fate of ob-asymptote.el
Hello Ihor. Ihor Radchenko writes: > Max Nikulin writes: > >>> Is major-mode for editing asymptote code available easily? >>> I was unable to find anything relevant in ELPA and non-GNU ELPA. >> >> I am not an asymptote user, but the following suggests that it may be >> installed with asymptote package >> >> https://packages.debian.org/file:asy-mode.el > > Confirm. I also do see an "emacs" use-flag in asymptote Gentoo package. That seems to also be the case for Fedora: sh-5.1$ dnf provides "*site-lisp/asymptote/asy-mode.el" symptote-2.81-1.fc36.x86_64 : Descriptive vector graphics language Repo: @System Matched from: Other : *site-lisp/asymptote/asy-mode.el > Then, would it make more sense to include ob-asymptote.el into the > asymptote distribution? I do not think this is a good idea: - I am not involved in the development of asymptote, so this solution would put maintenance of ob-asymptote.el beyond my reach. - I have no idea whether developers of Asymptote have any interest in Org. - Comparing to another language: what is the situation e.g. with Haskell? We have ob-haskell.el (thanks to Lawrence Bottorff). In my distro at least, I have Haskell mode installed separately. Should we then move ob-haskell.el into the package supplying Haskell mode? - Somehow I also think that the proposed solution would be close to the idea of including ob-C.el into a C compiler distribution. All the best, Jarmo
