Re: [BUG] Freeze with org-adapt-indentation set to headline-data

Ihor Radchenko wrote: > Fixed on main. Confirmed, thank you very much for the lightning fast fix! David

[BUG] Freeze with org-adapt-indentation set to headline-data

Hi all, I've hit a freeze when setting org-adapt-indentation to headline-data. I've bisected it to commit 0a6a56, "org-adapt-indentation: Fix 'headline-data checks". I can reproduce it in Emacs 28.2 on macOS with the following minimal init file: (add-to-list 'load-path "~/repos/org-mode/lisp")

Re: Code block syntax highlighting in async export

> I have realized that > https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-elisp.html > has colorized source blocks. The file is created using > https://git.sr.ht/~bzg/worg/blob/master/publish.sh and the script is > executed inside a container with no available DISPLAY. Well spotted! I

Re: Code block syntax highlighting in async export

> I'll investigate if I can leverage any of the workarounds mentioned. So, for batch processing, avoiding --batch or --script and just using --load with a script that either ends by killing Emacs, or killing it via an additional --eval, works, i.e. syntax highlighting uses colors. This was

Re: [PATCH] ox-odt: Prevent auto-formatting in export buffers

Noted, will do! David

Re: Code block syntax highlighting in async export

> Could you please provide an example? > Certainly more details is necessary, even export format (backend) is not > specified. Sorry for that! I somehow thought that the issue would sound familiar to more seasoned Org users, and someone would come back with either "yeah, you need to do X" or

Re: CDATA auto aggregation

OK, thanks! Just sent the patch. I realized in my original one (https://list.orgmode.org/20220228140750.75761-1-dafydd.lu...@gmail.com/), I'd also gotten rid of the with-temp-buffer in ox.el as long as I was switching to write-region, because write-region can write a string directly, but as

Code block syntax highlighting in async export

Hi all, I get different syntax highlighting in code blocks when using async export: no colors, just bold, italics and underlines. Is this expected, and if so, is there maybe an easy fix I just don’t know about? I found a similar problem in [batch export], but the workaround seems relatively

Re: CDATA auto aggregation

No worries! I'd forgotten about it myself, until it bit me again on Thursday, and I hit upon Diego's post while googling (because I thought at first my patch had been long since merged, and assumed it was a different issue). I'm happy to update the patch for ODT, but just FYI, I still don't have

Re: CDATA auto aggregation

Diego Rodriguez writes: > Where does this CDATA tag gets added automatically and how can I modify this > behavior? Do you have auto-formatting on save configured in Emacs -- perhaps even via a starter kit like Doom Emacs, so that you're only half aware of it? And are you by any chance on

Re: [PATCH] oc-basic.el: Stringify year from CSL-JSON date-parts

Thanks! OK, will do, thanks for letting me know. David

Re: [PATCH] ox.el: Protect export from auto-formatting hooks

Please ignore this patch! Apologies, as I was sending another patch today, I thought I hadn't followed up on my earlier promise to send a patch for this issue. It turns out I have, it just hasn't been reviewed/merged yet: https://list.orgmode.org/20220228140750.75761-1-dafydd.lu...@gmail.com/ (I

Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)

Bruce: Understood, I was just thinking forward :) Thank you for the details. As far as I'm concerned, EDTF in CSL JSON sounds like a good idea (but it's not like my opinion should particularly matter). Ihor: Thank you for the feedback! I'll send a proper patch then. Best, David

Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)

> I created CSL, and have helped develop the data schema. Well, that's what I call a reliable source :) I suppose this is as good a time as any to say thanks for all that! > it's likely we'll change the date property to prefer an > EDTF string Will that be stored in the `raw` or `literal`

Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)

> I suspect that multiple json formats may be available in the wild. Some > parsed as a list of strings and some parsed as a list of numbers. > The JSON schema allows either: Ah, thanks for looking this up! So (format "%s" (caar date)) instead of (number-to-string (caar date))? (That was

oc-basic: CSL-JSON year as number vs. string (nativecomp?)

Hi all, I've run into more problems with CSL-JSON support in oc-basic (previously: https://list.orgmode.org/caeptpexczkgam3v-brzezfcwmm4h3hqtoq+89qg+5uljq1k...@mail.gmail.com/). I recently started to get errors like the following: Error during redisplay: (jit-lock-function 544) signaled

Using pandoc to convert LaTeX math to MathML

Hi all, I recently wanted to set up LaTeX-to-MathML conversion in Org exports and got a bit frustrated trying to get either of the two options recommended in the docs (MathToWeb and LaTeXML) to work. But then I realized I should be able to use Pandoc for this -- and indeed, `(setq

Re: Protect Org export from auto-formatting hooks

Great, will do :) I realized at the last minute that some `save-buffer' calls in `ox-odt.el' also need to be amended separately (I was mostly testing these tweaks with HTML export, as it's faster / simpler). If it's problematic, we can have that discussion over the patch once I've submitted it.

Re: Protect Org export from auto-formatting hooks

> What about using `write-region' instead of `write-file' and not touching > `set-auto-mode' function? Thanks, that's indeed a much better way of doing it :) One can even avoid the temp buffer altogether and write the `output' string directly with `(write-region output nil file)`. Shall I

Protect Org export from auto-formatting hooks

Hi all, I recently started using non-Pandoc Org exports to HTML and ODT and noticed some problems on my macOS 12.2.1 box. Non-ASCII characters were coming out garbled, the whitespace around footnotes was getting rewritten in weird ways. On my Linux boxes, the same export commands went fine, so I

Re: More robust CSL-JSON date parsing in oc-basic

Thanks for the quick feedback! I'll send the patch momentarily. Best, David

More robust CSL-JSON date parsing in oc-basic

Hi all, I think I've found an opportunity to make oc-basic a bit more resilient w.r.t. different kinds of CSL-JSON publication date input. I encountered the following error: Error (org-mode-hook): Error running hook "org-fancy-priorities-mode" because: (error Unknown CSL-JSON date format:

Re: org-indent-indentation-per-level may be broken

> No trouble, sometimes the “main people” (Bastien, Nicolas, …) end up > being a bit snowed under and things take a bit longer than one might > hope, but we’ll always try to get back to you . I realize that, I hope I didn't sound snarky, I was being genuinely thankful :) > Would you care to

Re: org-indent-indentation-per-level may be broken

Hi Timothy, Thanks for getting back to me! > Is the patch in your original email a good fix for this? Basically yes, though I've simplified it to this: --8<--->8-- diff --git a/lisp/org-indent.el b/lisp/org-indent.el index

Re: org-indent-indentation-per-level may be broken

Correction, the following is not the case: > because when I set [org-indent-indentation-per-level] to e.g. 5, I > would expect the amount of indentation when I run org-indent-mode to > increase appropriately, but it doesn't, it's the same as with the > default value of 2. I got confused when

org-indent-indentation-per-level may be broken

Hi all, I'd like to use visual-line-mode to soft-wrap lines in Org files, while keeping continuation lines in list items properly indented: - long line that goes on to the edge of the screen and soft wraps like I want it to Instead of this: - long line that goes on to the edge of the screen