auctex
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Indenting the code written in square brackets as optional parameters


From: Sašo Živanović
Subject: Re: Indenting the code written in square brackets as optional parameters
Date: Wed, 9 Mar 2022 13:04:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2

Hi!

Ikumi Keita je 8. 03. 22 ob 17:59 napisal:
[ Including Sašo in To:, not to diverge discussion in two mail lists. ]
Thanks! I have subscribed to auctex-devel now, to make everybody's life a bit easier. ;-)

Sašo Živanović <saso.zivanovic@guest.arnes.si> writes:
Especially, how does your patch work in the presence of valid interval
notation like [1,10[ or [1,10)?  Will that break indentation for the
remainder of the whole document?
For [1,10[  yes it will break it
but closing braces in the comment can prevent that:
[1,10[%]]

Unlike my patch, yours counts commented braces, which changes the
current AUCTeX behavior. I'm a bit afraid that breaks indentation in
other contexts. (Hmm, but such cases must be rather rare, so it wouldn't
matter much?)
> Arash Esbati je 8. 03. 22 ob 19:34 napisal:
> I agree, we shouldn't change the current behavior big time.
And I also agree, the default behaviour should stay the same.

I have to admit I have been using my own patch for such a long time I actually forgot that counting commented braces in not the default AuCTeX behaviour! And also, that I'm not sure whether I changed this behaviour on purpuse or by accident ;-)

However, as a long-time user of the []-based indentation, I can confidently say that counting *brackets []* (not braces {}) in comments is quite crucial for user's happiness. And not only in math mode, as noted by others in this thread, also in text (well, programming) mode, as in:
\def\memoize{%
  \@ifnextchar[\memoize@opt\memoize@noopt%]
}

There might even be another usage case for taking commented delimites into account, indenting \ifs:
\ifx ... %[
  ...
\fi %]
(I'm totally alergic to non-indented \ifs, and have even tried to hack into that, but due to the coexistence of TeX- and LaTeX-style \ifs, this seems impossible to implement in general.)

Summing up: while I find []-indenting indispensable for Forest trees, and TikZ in general, I would definitely want to have an way to override it for specific cases, and counting stuff in comments seems the simplest way to implement the override.

On the other hand, I have a hard time imagining a situation where I would want to override a {}-based indent via a comment, so I would say that the AuCTeX's current behaviour to ignore these in comments makes perfect sense and should be kept (even without the historical reasons). So I would propose that the extended indenting mechanism would ignore {} in comments but count all other delimiters.

Finally, I believe that if we're about to extend the indenting mechanism, it makes sense to implement in generally enough to allow for arbitrary, and configurable, delimiters. For one, we can then set the default to {} to guarantee unchanged default behaviour. Secondly, I got quite attached to seeing stuff like this:
------
develop a syntactic counterpart to conservativity (recall the
  discussion of generalized quantifiers in
  section~\ref{cha:generalized-quantifier-theory}), and ultimately our
understanding of determiners and the nature of quantification in natural
language itself.
------
And perhaps someone will develop a package using <> as delimiters for whatever, etc.

Maybe I should modify `TeX-brace-count-line' instead of introducing a
new function `LaTeX-brace-count-line'. Currently I'm not sure which is
better.
Grep says that `TeX-brace-count-line' is only used in `latex.el'. So I guess that modifying this function should be better. (By the way, in my patch, I didn't modify it as much as rewrite it completely. Seeing Ikumi's patch, I realize that was certainly an overkill stemming from my inadequate Lisp knowledge. So thanks Ikumi for the opportunity to learn some Lisp!)

Best,
Sašo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]