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&utm_medium=web2x&context=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.el 2021-08-11 09:30:45.000000000 +0200 +++ b/org-indent.el 2021-08-11 10:45:13.000000000 +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
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
[-- Attachment #1: Type: text/plain, Size: 647 bytes --] Hi David, > I got confused when testing the different variations, I was expecting > the indentation change to happen in the wrong place. Sorry for that! Glad to hear it’s not as bad as you initially thought. > 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. Mmmm, that’s a pity. Is the patch in your original email a good fix for this? If not, would you be willing to try to make a patch that neatly solves the 0 issue? All the best, Timothy
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
[-- Attachment #1: Type: text/plain, Size: 762 bytes --] Hi David, > Thanks for getting back to me! 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 🙂. >> Is the patch in your original email a good fix for this? > > Basically yes, though I’ve simplified it to this: > *snip* Thanks for this, it’s nice to see something so simple. Would you care to make a “proper” patch (commit message and all 😉) so we can apply it to the repo giving you credit? If you haven’t assigned the FSF copyright, you’ll just need to add “TINYCHANGE” to the end of the commit message as per <https://orgmode.org/contribute.html>. All the best, Timothy
> 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 > <https://orgmode.org/contribute.html>. 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