[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
- Re: Indenting the code written in square brackets as optional parameters, (continued)
- Re: Indenting the code written in square brackets as optional parameters, Denis Bitouzé, 2022/03/04
- Re: Indenting the code written in square brackets as optional parameters, निरंजन, 2022/03/04
- Re: Indenting the code written in square brackets as optional parameters, Ikumi Keita, 2022/03/04
- Re: Indenting the code written in square brackets as optional parameters, निरंजन, 2022/03/05
- Re: Indenting the code written in square brackets as optional parameters, Ikumi Keita, 2022/03/06
- Re: Indenting the code written in square brackets as optional parameters, Arash Esbati, 2022/03/08
- Re: Indenting the code written in square brackets as optional parameters, Ikumi Keita, 2022/03/08
- Re: Indenting the code written in square brackets as optional parameters, Arash Esbati, 2022/03/08
- Re: Indenting the code written in square brackets as optional parameters,
Sašo Živanović <=
- Re: Indenting the code written in square brackets as optional parameters, निरंजन, 2022/03/09
- Re: Indenting the code written in square brackets as optional parameters, Sašo Živanović, 2022/03/09
- Re: Indenting the code written in square brackets as optional parameters, Arash Esbati, 2022/03/09
- Re: Indenting the code written in square brackets as optional parameters, Ikumi Keita, 2022/03/10
- Re: Indenting the code written in square brackets as optional parameters, Ikumi Keita, 2022/03/16
- Re: Indenting the code written in square brackets as optional parameters, Arash Esbati, 2022/03/16
- Re: Indenting the code written in square brackets as optional parameters, Ikumi Keita, 2022/03/16
- Re: Indenting the code written in square brackets as optional parameters, निरंजन, 2022/03/16
- Re: Indenting the code written in square brackets as optional parameters, Sašo Živanović, 2022/03/16
- Re: Indenting the code written in square brackets as optional parameters, Arash Esbati, 2022/03/18