bug#65648: 13.2; indentation of nested environments

[Paul Nelson]

Hi Uwe,

Thanks for your response.  First I'll respond to the minor points:

> You say indent-region
>
> I am referring here to the LaTeX-filling-functions, such as
>  LaTeX-fill-environment,  LaTeX-fill-section etc

There's no important difference here between indent-region and the
LaTeX fill commands -- unless I'm mistakaen, they all ultimately call
LaTeX-indent-line, one line at a time.  The same issue occurs for
both.

> Since I receive a *lot* of theses badly (in the sense above)
> environments in the incorrect form
> So I came up with a solution heavily rewritten and improved by Arash

I'm likewise often enough in this situation, motivating my proposal.
My workaround is "czm-tex-edit-fix-buffer", available at the very
bottom of 
https://github.com/ultronozm/czm-tex-edit.el/blob/main/czm-tex-edit.el,
which makes each \begin and \end in the buffer appear on their own
line.  I suspect it's similar enough to what you use.

The point of this bug fix is not really for me -- I get around it
through a combination of being diligent about inserting environments
and the linting function that I linked above -- but for new users who
I don't think should have to do that.

OK, on to the main point.  My claim is that if you care about your
example, namely

#+begin_src latex
\begin{equation}*
  \begin{aligned}**
    &n u m=\left[\begin{array}{ll}***
                   2 & 25
    \end{array}\right] \\
    &d e n=\left[\begin{array}{lll}
                   1 & 4 & 25
    \end{array}\right]
  \end{aligned}
\end{equation}
#+end_src

then you should care even more about the following simpler, more
natural, and (in my experience) more common example:

#+begin_src latex
\begin{equation}
  n u m=\left[\begin{array}{ll}
                   2 & 25
    \end{array}\right] \\
\end{equation}.
#+end_src

Let's put three of those examples in a row and format them according
to current AUCTeX and my proposal.

Current AUCTeX:
#+begin_src latex
\begin{equation}
  n u m=\left[\begin{array}{ll}
                2 & 25
              \end{array}\right] \\
          \end{equation}

          \begin{equation}
            n u m=\left[\begin{array}{ll}
                          2 & 25
                        \end{array}\right] \\
                    \end{equation}

                    \begin{equation}
                      n u m=\left[\begin{array}{ll}
                                    2 & 25
                                  \end{array}\right] \\
                              \end{equation}
#+end_src

My proposal:
#+begin_src latex
\begin{equation}
  n u m=\left[\begin{array}{ll}
                2 & 25
  \end{array}\right] \\
\end{equation}

\begin{equation}
  n u m=\left[\begin{array}{ll}
                2 & 25
  \end{array}\right] \\
\end{equation}

\begin{equation}
  n u m=\left[\begin{array}{ll}
                2 & 25
  \end{array}\right] \\
\end{equation}
#+end_src

The current AUCTeX indentation here is obviously broken; the primary
purpose of my proposal is to fix that.  I should emphasize that such
behavior arises in ways other than via indent-region or filling
commands, since many actions (inserting newlines, closing out
environments via C-c ], ...) ultimately invoke LaTeX-indent-line.

The difference between my proposal and the "optimum" that we agree on, namely
#+begin_src latex
\begin{equation}
  n u m=\left[\begin{array}{ll}
                2 & 25
              \end{array}\right] \\
\end{equation}
#+end_src
seems to me a secondary matter, or a fine-tuning.  The "user fix"
(always putting \begin on a fresh line) for the deficiency with my
proposal is the same as for the deficiency with current AUCTeX, but
the impact of the former seems to me much less catastrophic than that
of the latter.

> What's about a new variable then.
>
> (defvar LaTeX-fill-sloppy t
>   "When t, Paul's proposal, when nil, Uwe's proposal, that is the old 
> behavior")
>
> Or does this make the code more difficult to maintain?

It seems possible to fine-tune the indentation code to give the
"optimum", at the cost of making that code slightly less efficient due
to additional checks for matching \begin's.  I think that if any "new
variable" should be given, then its purpose should be to determine
whether to give such a fine-tuning, and not whether to fix the noted
"obviously broken" behavior.

Thanks, best,

Paul