Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

[Ihor Radchenko <yantar92@posteo.net>]

Sébastien Miquel <sebastien.miquel@posteo.eu> writes:

> Ihor Radchenko writes:
>> Confirmed.
>> This is caused by `org-src--contents-for-write-back' not adjusting
>> blank line indentation in some cases.
>
> I don't think that's the issue. In fact, applying your diff didn't
> seem to solve the issue on my end.

You are right.

> To fix the original issue, you can set =indent-tabs-mode= to =nil= in
> your org files, or possibly set =org-preserve-indentation= to =t=
> (untested).

Sure. Or passing -i switch. But that's wrong, IMHO.
Org mode files should be portable. We are aiming for universal
Emacs-independent markup. The value of `indent-tabs-mode' must not
affect Org markup - third party apps should be able to read src block
code without knowledge about Emacs minor modes being active when the Org
file is created. And Org files should not be broken for other users with
different settings for indent-tabs-mode.

> Generally, if you edit the given yaml in a =C-c C-'= buffer and go
> back to the org buffer with the default configuration, spaces will be
> converted to tabs, because =indent-tabs-mode= is =t= in the org buffer.
>
> I don't think there's much that we can do about it. We could try to
> read the value of =indent-tabs-mode= in the native buffer and preserve
> it in the org buffer, but then the org buffer would have mixed
> indentation all over, and that's exactly what the current code tries to
> avoid.

I think that mixed indentation in the Org buffer is fine. In particular,
in verbatim-type environments.

Let me demonstrate another related problem that manifests more clearly:

1. emacs -Q /tmp/bug.org (new file)
2. C-c C-, s python :results output <RET>
3. M-x whitespace-mode <RET>
4. if True:<RET>
5. if True:<RET>
6. print("Yes")
7. Observe tab in front of print("Yes")
8. M-: (require 'ob-python) <RET>
9. C-c C-c yes <RET>
10. Observe python error

  File "<stdin>", line 3
    print("yes")
TabError: inconsistent use of tabs and spaces in indentation
[ Babel evaluation exited with code 1 ]    

We can, indeed, fix this problem as well by re-indenting the src code
body. But that is (1) awkward; (2) will not work if there happen to be a
language that actually uses mixed indentation - by converting tabs to
spaces we are ultimately using the original info about src body.

I feel that we will be getting various edge cases like the original
report and like the one I made up above if we keep trying to convert
tabs/spaces. Just retaining the original code indentation will be much
more robust, IMHO.

>   - =preserve-fl= is an isolated issue, and only concerns LaTeX
>     fragments. I will attach a test with the issue it solves with
>     multiline LaTeX fragments. I think LaTeX fragments are particular
>     because in the org buffer they do not need to start at the
>     beginning of a line.

> ... "- Item $abc<point>\n  efg$"

Shouldn't newlines be removed completely before editing the body here?
Just like what we do for inline src blocks. See `org-babel--normalize-body'.

> Here are three patches attached.
>   1. Two tests : about editing LaTeX fragments, and preserving empty
>      lines.

LGTM.

>   2. Renaming of =preserve-blank-line=, for clarity.

My concern is for `newline-and-indent'. Current line is _previous_ line
in such scenario, not the newly inserted line.

>   3. Two more tests testing the behaviour of =org-return= and
>      indentation, with the default configuration. When writing these, I
>      found the behaviour was buggy in one case, and modified
>      =org-indent-line= to fix it.

Let's discuss indent-tabs-mode first. I do not yet have a clear
picture about the best Org behaviour.

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