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

[David Lukeš]

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

[David Lukeš]

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")
(require 'org-loaddefs)
(setq org-adapt-indentation 'headline-data)

The freeze is perhaps best explained visually, please see here:
https://trnka.korpus.cz/~lukes/files/headline-data.mp4

Commentary / reproduction steps:

1. Open an Org file.
2. Type a level 1 heading, e.g. * foo, then RET.
3. Type a level 2 heading, e.g. ** bar, then RET.
4. Type RET a few more times -- works fine.
5. Go back to the level 2 heading line (C-p), jump to its end (C-e), press RET.
6. Press RET a few more times. No additional lines get inserted, Emacs
freezes (a spinner gets displayed, see video), C-g has to be used to
interrupt this.

A few more observations:

- After step 5, if you type a few regular characters first (letters,
numbers) and only then RET, no freeze occurs.
- After step 5, you can also type just a series of spaces, and no
freeze occurs while typing those spaces, but as soon as you type a RET
(i.e., a RET after a line which consists only of spaces), the freeze
triggers.

Not sure if this reproduces on Linux, I'm traveling ATM, so I don't
currently have access to a Linux box unfortunately.

Let me know if I can provide any additional information!

Best,

David

Re: Code block syntax highlighting in async export

[David Lukeš]

> 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 think the trick there is setting
org-html-htmlize-output-type to 'css. See the variable's
documentation:

  Choices are css to export the CSS selectors only,inline-css
  to export the CSS attribute values inline in the HTML or nil to
  export plain text.  We use as default inline-css, in order to
  make the resulting HTML self-containing.

  However, this will fail when using Emacs in batch mode for export, because
  then no rich font definitions are in place.  It will also not be good if
  people with different Emacs setup contribute HTML files to a website,
  because the fonts will represent the individual setups.  In these cases,
  it is much better to let Org/Htmlize assign classes only, and to use
  a style file to define the look of these classes.
  To get a start for your css file, start Emacs session and make sure that
  all the faces you are interested in are defined, for example by loading files
  in all modes you want.  Then, use the command
  M-x org-html-htmlize-generate-css to extract class definitions.

So, still a workaround, technically, but a nice and clean one that
definitely deserves to be mentioned in this context!

Best,

David

Re: Code block syntax highlighting in async export

[David Lukeš]

> 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 suggested in [1]. As [2] points out, adding -nw removes the
colors, and so does adding --daemon (suggested in [3]), so don't do
either.

Enabling font-lock-mode manually and defining all the fontification
(see [4]) sounds like it would also work, but honestly, that's too
involved, so I didn't try it.

Using an external colorizer (as shown in [5]), seems like a good
alternative, if non-Emacs dependencies are acceptable.

These two last options can also be made to work with async export (my
original question), where you don't have control over how the batch
instance of Emacs is invoked.

> There’s a decent chance that `engrave-faces' (a package of mine that can now 
> be
> used for code blocks in LaTeX) will work in batch mode. Integrating it with
> `ox-html', `ox-ansii', and `ox-odt' are all (distantly) on my todo list.

Sounds great! If it will work in regular batch mode, then it should
work with async as well :)

Best,

David

[1] 
https://list.orgmode.org/orgmode/vZh_aXsUhlwNcRMF3miS6hNUo6xxUCFuzm4dwfCNQHcm4Ib53t8sJVVJ-PmYD4sRfoCvWRjtEG7L5rfN4pRe5nDxLFWxWEG8ZqcZ5YvJyDs=@protonmail.com/
[2] 
https://list.orgmode.org/orgmode/YmBR481ZMgZpA6svOfEMt3nYa8UPEKgvFUY5s8SpRWu2YdJz0pb0gPz8ajcTeKFbF7SD1fD9XibICa8Z-JdTiIqgjOlD1y4yg9uHCB176ZA=@protonmail.com/
[3] https://list.orgmode.org/orgmode/87a6923dbw.fsf@localhost/
[4] https://list.orgmode.org/ae5693f1-f63d-4383-8840-0fd2dbaac...@gmail.com/
[5] https://linevi.ch/en/org-pygments.html

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

[David Lukeš]

Noted, will do!

David

Re: Code block syntax highlighting in async export

[David Lukeš]

> 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 "yeah, that's a known limitation".

The export backend is HTML. In case anyone wants to try reproducing
this, I made a minimal working example here:
https://github.com/dlukes/org-html-a-sync-export-syntax-highlighting

> A problem that has some similar symptoms:
> M. Pger. Re: no syntax highlighting for code blocks with org-publish.
> Mon, 18 Jul 2022 22:55:15 +.
> https://list.orgmode.org/inTtQOKWAhnFydjBE9fQOOdo_oV6kIPG5_E0d8DsfFiYMIJ4RNLRk68Id6dyrzy1qIDK8YJu0Wty7objv22vR31PNrh-qB9vKxMgHPxNAu8=@protonmail.com

This looks indeed very similar, thank you! I'll investigate if I can
leverage any of the workarounds mentioned.

Best,

David

Re: CDATA auto aggregation

[David Lukeš]

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 that's not strictly necessary, I didn't include this
change in the updated patch, just the ox-odt.el stuff. Hope that's OK.

David

Code block syntax highlighting in async export

[David Lukeš]

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 complicated and brittle.

Alternatively, if this is an inherent limitation of async/batch export,
I’m thinking maybe [using an external colorizer like pygments] might be
the simpler option.

Thanks for any tips!

Best,

David


[batch export] 

[using an external colorizer like pygments]

Re: CDATA auto aggregation

[David Lukeš]

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 the FSF copyright assignment sorted out, which you warned me
about since my tinychanges are accumulating. I've been in contact with
both the FSF and my university, and long story short, the easiest way
is probably for me to wait until I graduate (hopefully a few months
from now) so that I don't need a university disclaimer at all.

Best,

David

Re: CDATA auto aggregation

[David Lukeš]

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 macOS, which ships with the tidy program
(HTML Tidy) by default? Or failing that, did you install it manually?

To cut a long-story short: HTML auto-formatting on save runs tidy, which
mangles the HTML in various ways, including this CDATA thing. This also
happens in buffers with generated Org export output.

I posted the long version to the mailing list in February:
https://list.orgmode.org/CAEPTPEwOZjJLX1jyFmVR6jarsocyuD=zf7hj1i9g4sfwk4m...@mail.gmail.com/

I suggested a patch, but it probably got buried in the noise:
https://list.orgmode.org/20220228140750.75761-1-dafydd.lu...@gmail.com/

Instead, I see that another fix was merged yesterday (for different
reasons AFAICS, but it should help with this auto-formatting issue too):
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d7a55bbd537314d2776b082bd92a1a08b3edc84e

This should be enough for HTML exports, but two more tweaks are needed
for ODT exports in ox-odt.el -- see my original patch. Or use
https://github.com/kjambunathan/org-mode-ox-odt, which has already
incorporated them.

Tim Cross  writes:

> We probably should consider moving the existing ox-html to an ox-xhtml
> and implementing a new ox-html that is based on html5.

+1 on that, although obviously, I'm aware it's quite a chore.

Best,

David

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

[David Lukeš]

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

David

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

[David Lukeš]

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 didn't find it at first because I'd searched the mailing list
archive for my surname with diacritics, but the patch is signed with
my surname *without* diacritics.)

The earlier patch is better, please ignore this one. Sorry for wasting
everyone's time.

David

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

[David Lukeš]

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?)

[David Lukeš]

> 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` field? In that case, the
current implementation should work with (not too wild) EDTF strings.
If not, code will have to be added to extract the value from the
appropriate field.

> I'd prefer an explicit cond here. format "%s" may silently
> work on malformed json files and will mask issues with
> bibliography from the user.

Sure, good idea :)

> Would you mind creating a patch and possibly supplying a test
> that will make sure that the example file and similar are correctly
> parsed?

I'm attaching a patch (just the patch for now, no commit message), let
me know what you think, in particular the error message. What would be
an acceptable way to wrap the format string?

As for tests -- if `oc-basic.el` already had some, I'd try to see if I
can come up with something by analogy. But as it stands, I know too
little about Elisp, nothing about Elisp testing, and have too little
spare time, sorry :(

Best,

David
diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
index a937f75..f10b95b 100644
--- a/lisp/oc-basic.el
+++ b/lisp/oc-basic.el
@@ -189,7 +189,14 @@ Return a hash table with citation references as keys and fields alist as values.
 (cons 'year
   (cond
((consp date)
-(caar date))
+ (let ((year (caar date)))
+   (cond
+ ((numberp year) (number-to-string year))
+ ((stringp year) year)
+ (t
+   (error
+ "First element of CSL-JSON date-parts should be a number or string, got %s: %S"
+ (type-of year) year)
((stringp date)
 (replace-regexp-in-string
   (rx

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

[David Lukeš]

> 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 actually my initial solution, purely out of being defensive
and trying to make sure it doesn't break in yet a different way should
other things than numbers turn up in date-parts, even nil or such.
Then I thought it was too hamfisted and didn't have the time to make a
case for being so defensive here. But since it's needed even just to
be *compliant*, the case seems quite clear now.)

> Can you provide an example json file demonstrating the problem?

Sure, I'm attaching a short sample.

Best,

David


sample.json
Description: application/json

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

[David Lukeš]

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
(wrong-type-argument "Argument is not a string or a secondary string:
2007")

This patch makes them go away:

diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
index a937f7513..9e00310a4 100644
--- a/lisp/oc-basic.el
+++ b/lisp/oc-basic.el
@@ -189,7 +189,7 @@ Return a hash table with citation references as
keys and fields alist as values.
 (cons 'year
   (cond
((consp date)
-(caar date))
+(number-to-string (caar date)))
((stringp date)
 (replace-regexp-in-string
   (rx

In this case, date is an array of numbers, so (caar date) is a number
(the publication year). Converting it to a string is the obvious fix.

Not sure why I haven't run into this error earlier, but I switched to
Emacs 28 somewhat recently, so nativecomp may be the problem here? It
sure seems plausible it wouldn't like a number where a string is
expected.

Best,

David

Using pandoc to convert LaTeX math to MathML

[David Lukeš]

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
org-latex-to-mathml-convert-command "pandoc -f latex -t html5 --mathml
%I -o %o")' seems to work!

So I'm wondering -- is it maybe worth adding this option to the docs?
MathToWeb and LaTeXML are both relatively obscure compared to Pandoc.
What's more, chances are users will already have Pandoc installed, as
it enables additional export capabilities for Org.

What are your thoughts?

Best,

David

Re: Protect Org export from auto-formatting hooks

[David Lukeš]

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.

Best,

David

Re: Protect Org export from auto-formatting hooks

[David Lukeš]

> 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 prepare a patch? Or would you rather do it yourself, since it
was your idea?

Best,

David

Protect Org export from auto-formatting hooks

[David Lukeš]

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 thought this must be related to some encoding
assumptions Org makes that are slightly different on the two platforms.

Armed with my very limited knowledge of Emacs, Org Mode and Elisp, I
decided to dig into the Org codebase and try to figure out where the
corruption was happening. However, this turned out to be a wild goose
chase – up until the last moment where Org hands off to `write-file’ to
write the export to disk, the contents was fine.

Wanting to confirm this, I tried exporting to a buffer, where indeed,
the contents looked perfectly alright. *But as soon as I saved the
buffer, it got mangled.* This finally made me realize that the culprit
was somewhere else: in my auto-formatting setup. Before that, I hadn’t
realized that Org exports are done via a buffer, so I had no idea that
on-save hooks are run. But knowing this, everything started falling into
place.

It turned out to be a perfect storm of trickiness: I’m using Doom Emacs,
so I’d just enabled autoformatting via `(format +onsave)’. I don’t care
about HTML or XML formatting and never manually installed an
auto-formatter for those, so I was surprised to see the export
reformatted on save. The reason: macOS ships `tidy’ in its base
distribution, so it gets picked up as an auto-formatting provider.
Unfortunately, it’s a really old version (2006) which wreaks havoc on
non-ASCII UTF-8 bytes (details in [this Doom Emacs issue], if you’re
interested).

However, even a recent version of `tidy’ can have undesirable effects on
the export. For instance, I’ve confirmed that those aforementioned
footnote-related whitespace issues in ODT exports persist, even after
installing a new version of `tidy’ which handles UTF-8 correctly. This
is presumably due to `tidy’ re-arranging the XML in ways that affect
whitespace.

So I think Org should try to protect the export buffer from these
shenanigans as much as possible. The best way I can think of to achieve
that is to keep the export buffer in fundamental mode. This should
prevent all the mode-related code from running, potentially even making
the export speedier.

After some experimenting, the way I finally got this to work was by
locally overriding the `set-auto-mode’ function:

┌
│ diff --git a/lisp/ox.el b/lisp/ox.el
│ index 2a3edaa50..d5a77c26e 100644
│ --- a/lisp/ox.el
│ +++ b/lisp/ox.el
│ @@ -6462,14 +6462,16 @@ or FILE."
│   ',ext-plist)))
│ (with-temp-buffer
│   (insert output)
│ - (let ((coding-system-for-write ',encoding))
│ + (cl-letf ((coding-system-for-write ',encoding)
│ +   ((symbol-function 'set-auto-mode) #'ignore))
│ (write-file ,file)))
│ (or (ignore-errors (funcall ',post-process ,file)) ,file)))
│  (let ((output (org-export-as
│ backend subtreep visible-only body-only
ext-plist)))
│(with-temp-buffer
│  (insert output)
│ -(let ((coding-system-for-write encoding))
│ +(cl-letf ((coding-system-for-write encoding)
│ +  ((symbol-function 'set-auto-mode) #'ignore))
│(write-file file)))
│(when (and (org-export--copy-to-kill-ring-p) (org-string-nw-p
output))
│  (org-kill-new output))
└

What are your thoughts? Is this desirable? In my mind, yes: even if
someone has configured auto-formatting manually, they might still not
realize it’s getting run in a hidden buffer they never get to see. After
all, this is an implementation detail – if Emacs had a built-in function
to write a string to a file, I presume that would get used instead?

(In a way, I was lucky that I encountered quite noticeable issues with
mangled characters. With the recent version of tidy, which only messes
up whitespace, I might not have noticed at all.)

And if such protection is desirable, is this the best way to do it? Or
can you come up with a better approach?

Anyway, thanks for reading this far :)

Best,

David


[this Doom Emacs issue]

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

[David Lukeš]

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

Best,

David

More robust CSL-JSON date parsing in oc-basic

[David Lukeš]

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: nil)

(Based on the debugger traceback, what triggered it was citar loading
oc-basic for fontification purposes.)

After a small tweak to oc-basic (see below), the error message got a bit
more informative:

  Error (org-mode-hook): Error running hook "org-fancy-priorities-mode"
  because: (error Unknown CSL-JSON date format: ((literal . "2009 / 09 /
  01 /")))

Based on this, I ended up making the following changes to oc-basic:

--8<>8--

diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
index fc71d22fc..de9be40a1 100644
--- a/lisp/oc-basic.el
+++ b/lisp/oc-basic.el
@@ -178,21 +178,24 @@ Return a hash table with citation references as
keys and fields alist as values.
  " and ")))
  ('issued
   ;; Date are expressed as an array
-  ;; (`date-parts') or a "string (`raw').
-  ;; In both cases, extract the year and
-  ;; associate it to `year' field, for
-  ;; compatibility with BibTeX format.
+  ;; (`date-parts') or a "string (`raw'
+  ;; or `literal'). In both cases,
+  ;; extract the year and associate it
+  ;; to `year' field, for compatibility
+  ;; with BibTeX format.
   (let ((date (or (alist-get 'date-parts value)
-  (alist-get 'raw value
+  (alist-get 'raw value)
+  (alist-get 'literal value
 (cons 'year
   (cond
((consp date)
 (caar date))
((stringp date)
-(car (split-string date "-")))
+(replace-regexp-in-string
".*?\\([0-9]\\{4\\}\\).*" "\\1" date))
+
(t
 (error "Unknown CSL-JSON date
format: %S"
-   date))
+   value))
  (_
   (cons field value
  item)

--8<>8--

A few comments, starting from the top:

1. In practice, it looks like string-valued dates can either be tagged
   with 'raw or with 'literal. Not sure what the difference is, whether
   one is older or deprecated. I just know that my CSL-JSON (produced by
   Better BibTeX from Zotero) is full of the latter, and oc-basic didn't
   account for this possibility, so I added it.
2. I'm pretty sure the weird date format, "2009 / 09 / 01 /", is not
   something I entered manually. My preferred format would be
   "2009-09-01", which is what oc-basic currently expects. But with
   Zotero, I tend to rely on metadata being filled in automagically, and
   it looks like it's the Wild West out there. So I figured a more
   robust way to extract the year portion might be to match the first
   sequence of 4 digits, instead of splitting the string on - and taking
   the car of the resulting list.

   Of course, both are just heuristics, both can fail (each in different
   ways), and both can result in the entire string being used as the
   year. My suggested change is based purely on the fact that the
   4-digit heuristic more often does the right thing in my own
   collection of bibliography entries.
3. The last change uses value instead of date in the error message,
   which makes it more informative, as shown above -- when encountering
   a problem, the user gets to see the offending entry, instead of just
   nil.

Let me know which of these changes -- if any -- seem acceptable, and
whether they qualify as tinychange, and I'll happily submit a proper
patch :)

Best,

David

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

[David Lukeš]

> 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 make a “proper” patch (commit message and all ) so
> we can apply it to the repo giving you credit?

Sure, sounds great, I'll try and send one in a minute! Let's see how it
goes.

> If you haven’t assigned the FSF copyright, you’ll just need to add
> “TINYCHANGE” to the end of the commit message as per
> .

When properly formatted, the patch looks bigger than it actually is, but
I'm assuming that's not a problem -- that the number of lines of code is
computed using something like "git diff -w"?

David

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

[David Lukeš]

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 ea7ea07..2091083 100644
--- a/lisp/org-indent.el
+++ b/lisp/org-indent.el
@@ -126,6 +126,7 @@ useful to make it ever so slightly different."
(make-vector org-indent--deepest-level nil))
   (setq org-indent--text-line-prefixes
(make-vector org-indent--deepest-level nil))
+  (when (> org-indent-indentation-per-level 0)
   (dotimes (n org-indent--deepest-level)
 (let ((indentation (if (<= n 1) 0
 (* (1- org-indent-indentation-per-level)
@@ -150,7 +151,7 @@ useful to make it ever so slightly different."
(concat (make-string (+ n indentation) ?\s)
(and (> n 0)
 (char-to-string org-indent-boundary-char)))
-   nil 'face 'org-indent)
+   nil 'face 'org-indent))

 (defsubst org-indent-remove-properties (beg end)
   "Remove indentations between BEG and END."

--8<--->8--

It turns org-indent--compute-prefixes into a no-op, except for
initializing the various prefix vectors, on the assumption that when
org-indent-indentation-per-level is 0, there should simply be no
prefixes.

Disclaimer: I didn't really try to understand the entire reasoning
behind how the prefixes are computed, why it's done the way it's done,
what are the various edge cases etc. But AFAICS, my patch shouldn't
break anything that was working before: when
org-indent-indentation-per-level is greater than 0, everything runs as
before. And when it's 0, then instead of an error, something reasonable
now happens.

If there are disagreements about the details of what should happen, then
they can probably be discussed after this stopgap patch gets merged. For
instance, maybe there's a feature of Org Mode I don't use and which
should get some special treatment when org-indent-indentation-per-level
is 0. But seeing as no one seems to have been inconvenienced by the fact
that it didn't work at all until now, I'm not expecting much of an
uproar :)

Also, maybe it would still make sense to change (if (<= n 1) 0 ...) to
(max 0 ...), as a more catch-all way to ensure that indentation is
reliably greater than 0 (so that (make-string indentation ?*) doesn't
fail)? It's not needed with the when-condition placed as it is in the
patch above, but maybe just to be on the safe side. Dunno.

Best,

David

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

[David Lukeš]

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 testing the different variations, I was expecting
the indentation change to happen in the wrong place. Sorry for that!

So to be clear: setting org-indent-indentation-per-level to 0 is broken
and leads to the aforementioned error. Setting it to a value >0 behaves
correctly, as in, the indentation of the heading levels changes
accordingly.

Cheers,

David

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

[David Lukeš]

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 and soft wraps
like I *don't* want it to

I figured it should be possible to achieve this with org-indent-mode.
However, that mode also adds visual pre-indentation for each heading
level, which I'd rather avoid, I'd like the content under the headings
to start flush with the left margin. So the overall result should look
like this:

* Heading
- long line that goes on to the edge of the screen and soft wraps
  like I want it to

Not like this:

* Heading
  - long line that goes on to the edge of the screen and soft wraps
like I want it to

I thought I could achieve this by setting
org-indent-indentation-per-level to 0, and historically, people seem to
have been able to use it for this purpose [1] (if I understand the
comment correctly).

[1]: 
https://www.reddit.com/r/emacs/comments/97naje/what_is_everyones_org_mode_indentation_preferences/e4a6qqt?utm_source=share_medium=web2x=3

However, when I set the option to 0 and start org-indent-mode, I
currently get the following error:

Debugger entered--Lisp error: (wrong-type-argument wholenump -1)
  make-string(-1 42)
  org-indent--compute-prefixes()
  org-indent-mode(toggle)
  funcall-interactively(org-indent-mode toggle)
  call-interactively(org-indent-mode record nil)
  command-execute(org-indent-mode record)
  execute-extended-command(nil "org-indent-mode" "org-indent-m")
  funcall-interactively(execute-extended-command nil "org-indent-mode"
"org-indent-m")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

So it seems like the logic that computes the actual indentation based on
org-indent-indentation-per-level is broken? And maybe in more than one
way, because when I set it 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.

FWIW, I can avoid the error and get the effect that I was originally
looking for by applying the following patch:

--- a/org-indent.el2021-08-11 09:30:45.0 +0200
+++ b/org-indent.el2021-08-11 10:45:13.0 +0200
@@ -130,8 +130,9 @@
 (make-vector org-indent--deepest-level nil))
   (dotimes (n org-indent--deepest-level)
 (let ((indentation (if (<= n 1) 0
+ (max 0
  (* (1- org-indent-indentation-per-level)
-(1- n)
+(1- n))
   ;; Headlines line prefixes.
   (let ((heading-prefix (make-string indentation ?*)))
 (aset org-indent--heading-line-prefixes
@@ -146,13 +147,14 @@
  (substring heading-prefix 1)))
 (t (org-add-props heading-prefix nil 'face 'org-indent)
   ;; Text line prefixes.
+  (if (> org-indent-indentation-per-level 0)
   (aset org-indent--text-line-prefixes
 n
 (org-add-props
 (concat (make-string (+ n indentation) ?\s)
 (and (> n 0)
  (char-to-string org-indent-boundary-char)))
-nil 'face 'org-indent)
+nil 'face 'org-indent))

 (defsubst org-indent-remove-properties (beg end)
   "Remove indentations between BEG and END."

But that's just a workaround for my particular case, setting
org-indent-indentation-per-level to values greater than 2 still has no
discernible effect after these changes.

Here are the contents of the init.el file I'm testing this with:

(setq org-indent-indentation-per-level 0
  org-adapt-indentation nil
  debug-on-error t)
(global-visual-line-mode 1)

And here's my version info:

GNU Emacs 27.2 (build 1, aarch64-apple-darwin20.3.0, Carbon Version
164 AppKit 2022.3) of 2021-06-11
Org mode version 9.4.6 (9.4.6-12-gdcc3a8-elpa @
/Users/david/.emacs.d/elpa/org-20210809/)

(Please let me know if I should provide some more!)

Best,

David