Weird behavior when `org-adapt-indentation` is set

[hammerfunctor]

Thanks for your work on this great package! I found some weird things on the cooperation between org, indent-region and org-modern and have no idea whether its a feature or a bug.

When org-adapt-indentation (a built-in variable) is set, indent-region is expected to indent heading, text and blocks to their correct level like this:

** A level-2 heading
   something

   something

   #+begin_quote
   a block
   #+end_quote

   and something

But when org-modern is turned on in this buffer, indent-region makes the region:

** A level-2 heading
   something

   something

            #+begin_quote
a block
            #+end_quote

and something

Every time I run indent-region, the block tag got indented once more, but the text after a block just remain unchanged.

Currently what I can do is define a function to turn off org-modern, indent and then turn on org-modern, and bind C-M-\ to it. Blocks get indented accordingly at this time, though they shouldn't.

[minad]

Thanks. I can reproduce the problem. It seems that org-indent-region or org-indent-line has issues computing the indentation if there are invisible/diplay properties on the line. This is not something we can fix in org-modern, since org-modern only augments the fontification and does not override indentation functionality. It should be repaired in Org directly if even - maybe ask on the Org issue tracker? I suggest you either don't use org-adapt-identation or set org-modern-block-name to nil. With org-modern-block-name=nil the issue also seems to go away.

[yantar92]

https://list.orgmode.org/als4q47p4dt4iva4s73sihe75qjdz4ni554h55e63o6izogzst@vs3olesw6da3/T/#m8d85b510def4163f8401988aaa44bf935027745f

I do not think that Org indentation is doing anything wrong here.

[minad]

@yantar92 Any suggestion how this should be fixed? I think the expectation is that the indentation function is based on the underlying text (in the sense that we treat Org as a text format) and not on the way the text is displayed. However somewhere in the indentation process the displayed representation is taken into account for the computations. Where does this happen, in indent-line-to?

[minad]

@yantar92 Nevermind. I saw that you already mentioned that indentation is based on "visual alignment" by convention.

I believe that it is org-modern's fault. Indentation works are it
supposed to and tried hard to align text visually to third column.
org-modern fights against.

Note that indenting visually is Emacs' convention that applies
everywhere.

My opinion is that the convention does not make much sense, but the convention is surely not going to change. For variable pitch fonts one can throw the convention out of the window right away, since there one will never achieve perfect indentation. Indentation via spaces only really works well for fixed pitch fonts and as such one could as well base it on the underlying text representation only.

@hammerfunctor I don't see a way to fix this. Therefore I suggest that you avoid org-adapt-indentation. You can disable org-modern-block-name prettification or try use org-indent-mode.

[yantar92]

Emacs does it. indent-to.

As for suggestions, you can maybe try line-prefix text property.

[yantar92]

@hammerfunctor I don't see a way to fix this. Therefore I suggest that you avoid org-adapt-indentation. You can disable org-modern-block-name prettification or try use org-indent-mode.

It has little to do with org-adapt-indentation. Any indentation will be problematic except 0.

[yantar92]

Daniel Mendler ***@***.***> writes:

@hammerfunctor I don't see a way to fix this. Therefore I suggest that you avoid `org-adapt-indentation`. You can disable `org-modern-block-name` prettification or try use `org-indent-mode`.

Note that `org-indent-mode` will also fight with org-modern once you start editing the buffer.

…

-- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>

[yantar92]

As for suggestions, you can maybe try line-prefix text property.

Ok. I looked into org-modern, and I do see that it is what you do already.
What you may try to do is not matching indentation spaces in
https://github.com/minad/org-modern/blob/main/org-modern.el#L736
Or, alternatively, you can put a display property that will ensure preserving indentation.

[minad]

@yantar92

Emacs does it. indent-to.

Understood. Thanks.

As for suggestions, you can maybe try line-prefix text property.

Not sure how this is going to work if I want to preserve the visual style of org-modern. I am not saying that org-modern is without downsides but so far it works well for me. Despite the styling, most elements stay editable for example (in contrast to svg tags). There are certainly problems in edge cases like this indentation issue. In the end it is the choice of the user if they prefer the plain text display or if they want some styling, same with settings like org-hide-emphasis-markers.

It has little to do with org-adapt-indentation. Any indentation will be problematic except 0.

My assumption is that Org is mostly not an indented format and org-adapt-indentation violates this assumption. You surely have a much better picture on how people actually use Org, but it seems to me that avoiding indentation is the current recommendation, perhaps inspired by other light markup formats like Markdown? Iirc older Org versions had a setting like org-adapt-indentation enabled by default?

Note that org-indent-mode will also fight with org-modern once you
start editing the buffer.

Where do you observe this fighting? The only styling which is incompatible with org-indent-mode is org-modern-block-fringe, but org-modern already disables this setting if org-indent-mode is enabled. The other settings should not lead to bigger issues. Prettification of the stars doesn't look nice in the presence of indentation due to misalignment, but I would not call this "fighting". One can try the following settings:

(org-indent-mode)
(global-org-modern-mode)
(setq org-modern-hide-stars ".")

[minad]

@yantar92

Ok. I looked into org-modern, and I do see that it is what you do already.
What you may try to do is not matching indentation spaces in
https://github.com/minad/org-modern/blob/main/org-modern.el#L736
Or, alternatively, you can put a display property that will ensure preserving indentation.

Right. I don't observe this issue with either one or both of the following settings, since then the spaces before the #+begin_src keyword are not hidden.

;; Disable problematic setting 1: Do not style fringe
(setq org-modern-block-fringe nil)

;; Disable problematic setting 2: Do not style block name
(setq org-modern-block-name nil)

The problem seems to be that we cannot fix the indentation issue without changing the styling at the same time. So you are right that the block styling fights with both indentation and also org-indent-mode. There exists already a small package by @jdtsmith which should avoid these problems by implementing the block styling differently, see https://github.com/jdtsmith/org-modern-indent. Unfortunately it has other downsides, e.g., incompatibility with line-spacing>0 and also higher complexity due to patching org-indent via advices. I try to avoid advices here if possible.

But given that org-modern-block-fringe (which is the actual root cause here) is so problematic I should maybe reconsider this feature, try some other implementation or disable it by default.

[yantar92]

Daniel Mendler ***@***.***> writes:

> Note that `org-indent-mode` will also fight with org-modern once you > start editing the buffer. Where do you observe this fighting? The only styling which is incompatible with `org-indent-mode` is `org-modern-block-fringe`, but `org-modern` disables this setting if `org-indent-mode` is enabled. The other settings should not lead to bigger issues. Prettification of the stars doesn't look nice in the presence of indentation due to misalignment, but I would not call this "fighting". One can try the following settings:

Try the recipe from https://list.orgmode.org/als4q47p4dt4iva4s73sihe75qjdz4ni554h55e63o6izogzst@vs3olesw6da3/T/#m84ce8f02c2bbf107b108b3470777c2d3609cef00 And then press C-j (or <RET>), inserting newline into the quote block.

…

-- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>

[yantar92]

The problem seems to be that we cannot fix the indentation issue without changing the styling at the same time. So you are right that the block styling fights with both indentation and also org-indent-mode

Maybe https://github.com/minad/org-modern/blob/main/org-modern.el#L741

Also, it is not necessary to set fringes via line-prefix/wrap-prefix. See "41.16.5 Displaying in the Margins" in Elisp manual:

To display something in the margin in association with certain
buffer text, without altering or preventing the display of that text,
put on that text an overlay with a ‘before-string’ property, and put the
margin display specification on the contents of the before-string.

[minad]

Try the recipe from
https://list.orgmode.org/als4q47p4dt4iva4s73sihe75qjdz4ni554h55e63o6izogzst@vs3olesw6da3/T/#m84ce8f02c2bbf107b108b3470777c2d3609cef00

I am not sure I understand. You introduce some misalignment using indent-to - this is the problem described in this issue. Then it makes sense that newlines lead to further misalignment.

On the other hand if I turn on org-indent-mode and then org-modern-mode I can insert and edit quote or src blocks without problems. The indentation in source blocks is not affected negatively - no fighting.

Maybe https://github.com/minad/org-modern/blob/main/org-modern.el#L741

Yes, exactly. This is the line which hides the spaces if both org-modern-block-name and org-modern-block-fringe are on.

Also, it is not necessary to set fringes via line-prefix/wrap-prefix. See "41.16.5 Displaying in the Margins" in Elisp manual:

Sure, but then we have to use overlays - something I try to avoid here for performance issues.

[yantar92]

Daniel Mendler ***@***.***> writes:

> Try the recipe from ***@***.***/T/#m84ce8f02c2bbf107b108b3470777c2d3609cef00 I am not sure I understand.

Let me elaborate. In the linked recipe, I meant that in (4) you instead move point to the end of #+begin_... line and then in (5) press <RET>.

> Also, it is not necessary to set fringes via line-prefix/wrap-prefix. See "41.16.5 Displaying in the Margins" in Elisp manual: Sure, but then we have to use overlays - something I try to avoid here for performance issues.

This is no longer necessary starting from Emacs 29, where overlays are re-implemented using proper segment tree and actually scale even better compared to text properties (what an irony...). That said, overlays are buffer-local, so font-lock approach will not work reliably.

…

-- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>