When adding a newline to an org-src block with
`org-src-tab-acts-natively' set to t, if there's a non-whitespace
character following the pointer at insertion, all other lines are
indented by an additional `org-edit-src-content-indentation'
regardless of their original indentation.
MRE with -Q on the current dev branch:
Put the pointer between foo and bar in the following src block and
press enter repeatedly.
#+begin_src fundamental
foobar
#+end_src
`foo' will float off to the right as it's indented by two spaces (or
however much `org-edit-src-content-indentation' is set to) with every
newline. In some modes, e.g. python, both `foo' and `bar' will float
to the right as you press enter.
If instead there are two (or more) whitespaces following the point of
the newline as such:
#+begin_src fundamental
foo bar
#+end_src
Pressing enter once with the pointer after `foo' will not indent `foo'
by another two characters, `org-indent-line' instead behaves as
when `org-src-tab-acts-natively' is set to nil.
What's happening is that before indenting, `org-remove-indentation'
removes indentation equal to the least indented line in the block,
which in this case is 0. It then inserts it in the src-edit buffer,
runs the modes indentation, and adds the org-src content indentation
again before reinserting it in the org buffer.
I've attached the monkeypatch that I cooked up for myself. It passes
tests and hasn't caused any issues for me yet, but Ihor's answers to a
similar sounding report [1] makes me a bit uncertain on what the
intended behavior is. I'm not really sure if might somehow be a
breaking change. If the behavior is unintended but this patch is
breaking, an alternative could be making `org-src-tab-acts-natively'
always reindent the entire block, but that seems overkill to me.
LRA
---------------------------------------------------------------------
[1] I think this is what this thread was about:
https://list.orgmode.org/CALp=Ckko1Ck7-3K+bfKXLVSqDJvmHWYEZutkj5J2v3t=quv...@mail.gmail.com/T/#tO
Which was closed as not a bug, but since I feel I'm misunderstanding
either the original report or Ihor's answer I thought to resubmit it.
If this is the intended behavior of `org-src-tab-acts-natively' I feel
it should be documented and consistent. IMO nothing in the description
of `org-src-tab-acts-natively' gives any reason to expect this behavior.
>From 6ce3ced7e2139b7343a692ca47457aaf2b38b19d Mon Sep 17 00:00:00 2001
From: Lukas Rudd Andersen <l...@phdk.org>
Date: Tue, 25 Mar 2025 12:49:24 +0100
Subject: [PATCH] lisp/org.el Fix unexpected indentation behavior in src blocks
* org.el (org-indent-line): Add spaces matching org-src indentation settings to current line before `indent-according-to-mode' is called.
When `org-src-tab-acts-natively' is set to t, if a newline is inserted with non-whitespace characters within the first `block-content-ind' characters, org does not properly delete the src block indentation before creating the edit buffer, resulting in overindentation when the contents of the edit buffer are reinserted.
TINYCHANGE
---
lisp/org.el | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lisp/org.el b/lisp/org.el
index e9f11db1e..649a0610f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19474,6 +19474,9 @@ Also align node properties according to `org-property-format'."
;; rather than `indent-line-function' here or we may
;; sometimes break `electric-indent-mode'
;; https://orgmode.org/list/5O9VMGb6WRaqeHR5_NXTb832Z2Lek_5L40YPDA52-S3kPwGYJspI8kLWaGtuq3DXyhtHpj1J7jTIXb39RX9BtCa2ecrWHjijZqI8QAD742U=@proton.me
+ (save-excursion
+ (beginning-of-line)
+ (insert-char #x20 block-content-ind))
(org-babel-do-in-edit-buffer (indent-according-to-mode)))
(when (and block-content-ind (looking-at-p "^$"))
(indent-line-to block-content-ind))))
--
2.47.2
