Sébastien Miquel <sebastien.miq...@posteo.eu> writes: > 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).
What about the following approach: When converting from org-src buffer back to Org, 1. We do not touch the original indentation, except minimal common indentation of the whole src code, respecting the src mode value of `indent-tabs-mode'. 2. Minimal common indentation is treated according to `org-src-preserve-indentation'. 3. `org-src-preserve-indentation', when in effect, will add extra indentation of #+begin indentation + `org-src-preserve-indentation', now honouring `indent-tabs-mode' in Org buffer. When converting from Org to org-src buffer, 1. When `org-src-preserve-indentation' is in effect, remove the common `org-src-preserve-indentation' + #+begin indentation from the body. >>> ... "- 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. May you provide an example? AFAIK, LaTeX usually treats newlines as whitespace, same with " ". >>> 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). I think I stumbled upon related problem in my testing, but can no longer reproduce. Your explanation indeed makes sense for my example. -- 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>