Ihor Radchenko writes:
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.

Python code being broken with the default configuration is
problematic, and fixing that seems worth the downsides (the
indentation in an org file will now partially depend on the
=indent-tabs-mode= settings of other modes, which cannot be set using
buffer local variables).

   - =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'.

I was not aware of how we treated inline src blocks, but I don't think
so. LaTeX fragments, in particular $$…$$ fragments, can have
significant (for the user) newlines.

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

   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.

The way =newline-and-indent= works, I think, is that a newline is
inserted, then =org-indent-line= is called, which preindents the line
to the common org indentation, then calls =TAB= in a native edit
buffer that does the rest of the indentation. The "current" line I
refer to in the code is the new line (the "current" line is the one
from which the native edit was called).

Sébastien Miquel

Reply via email to