[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65648: 13.2; indentation of nested environments
From: |
Uwe Brauer |
Subject: |
bug#65648: 13.2; indentation of nested environments |
Date: |
Sun, 03 Sep 2023 18:40:43 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
>>> "PN" == Paul Nelson <ultrono@gmail.com> writes:
Hi Paul
> 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.
I just had a look, very interesting, you also have a function
czm-tex-edit-make-equation-numbered
I also came up with something similar, again, heavily rewritten by Arash
(defun my-change-dollar-to-equation ()
(interactive)
(save-excursion
(replace-regexp "\\$\\$\\(\\(.\\|\n\\)*?\\)\\$\\$"
"\\\\begin{equation}\\1\\\\end{equation}")))
(defun my-change-dollar-to-equation-label ()
"Courtesy from Arash Esbati
[[https://groups.google.com/groups/search?as_umsgid=86fspsavpa.fsf@gnu.org][Email
from Arash Esbati: Re: change $$ to equations with automatic labels]]:
This function not only replaces displayed plain TeX equations with a `$$'
equations with
the `\begin{{equation}' environment, but it also inserts an
appropriate label via `reftex-label'"
(interactive)
(let ((p (point-marker))
(s (make-marker))
(e (make-marker)))
(goto-char (point-min))
(while (re-search-forward (concat "^" (regexp-quote "$$")) nil t)
;; Start doing something if we are in a math evn:
(when (texmathp)
(set-marker s (point))
;; Search for the closing $$ pair:
(re-search-forward (concat "^" (regexp-quote "$$")))
(set-marker e (point))
(delete-backward-char 2)
(insert "\\end{equation}")
(delete-horizontal-space)
(goto-char s)
(delete-backward-char 2)
(insert "\\begin{equation}")
(delete-horizontal-space)
;; Indent the environment:
(goto-char e)
(indent-according-to-mode)
(goto-char s)
(indent-according-to-mode)
;; Check if there is already a \label:
(unless (re-search-forward "\\\\label{" e t)
(goto-char s)
(forward-line)
(indent-according-to-mode)
(reftex-label)
(LaTeX-newline)
(indent-according-to-mode))))
(goto-char p)
(set-marker p nil)
(set-marker s nil)
(set-marker e nil)))
I think it might be a good idea somehow to try to combine these
functions. I also proposed/asked to add them to auctex, till now there
was not enough interest and it was considered a corner case.
> 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.
That of course is true.
> 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
Ok I see your point now
> 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.
I think the maintainers should decide that. I am in favor of such a
variable, however I don't know enough of the code to really judge it.
To summarise, you convinced me, sigh.
Not sure what the others think.
In case it gets adapted, then I will see how I can and will deal
with the new behavior maybe using some of your functions, and if I don't
succeed, I will complain again, 😉😇
Uwe
> Thanks, best,
> Paul
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
smime.p7s
Description: S/MIME cryptographic signature
- bug#65648: 13.2; indentation of nested environments, Ikumi Keita, 2023/09/03
- bug#65648: 13.2; indentation of nested environments, Uwe Brauer, 2023/09/03
- bug#65648: 13.2; indentation of nested environments, Paul Nelson, 2023/09/03
- bug#65648: 13.2; indentation of nested environments, Uwe Brauer, 2023/09/03
- bug#65648: 13.2; indentation of nested environments, Paul Nelson, 2023/09/03
- bug#65648: 13.2; indentation of nested environments,
Uwe Brauer <=
- bug#65648: [off-topic your packages] (was: bug#65648: 13.2; indentation of nested environments), Uwe Brauer, 2023/09/03
- bug#65648: [off-topic your packages] (was: bug#65648: 13.2; indentation of nested environments), Paul Nelson, 2023/09/03
- bug#65648: [off-topic your packages], Uwe Brauer, 2023/09/03
- bug#65648: 13.2; indentation of nested environments, Ikumi Keita, 2023/09/04
- bug#65648: 13.2; indentation of nested environments, Paul Nelson, 2023/09/04
- bug#65648: 13.2; indentation of nested environments, Ikumi Keita, 2023/09/09
- bug#65648: 13.2; indentation of nested environments, Paul Nelson, 2023/09/09
- bug#65648: 13.2; indentation of nested environments, Ikumi Keita, 2023/09/12
- bug#65648: 13.2; indentation of nested environments, Ikumi Keita, 2023/09/14
- bug#65648: 13.2; indentation of nested environments, Uwe Brauer, 2023/09/09