[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Indenting the code written in square brackets as optional parameters
From: |
Ikumi Keita |
Subject: |
Re: Indenting the code written in square brackets as optional parameters |
Date: |
Thu, 10 Mar 2022 19:14:36 +0900 |
Hi all,
>>>>> Arash Esbati <arash@gnu.org> writes:
> Sašo Živanović <saso.zivanovic@guest.arnes.si> writes:
>> 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%]
>> }
> That's a good example, I haven't that in my mind.
I think so, too.
By the way, I noticed other cases in math mode which should be taken
into account; \left-\right pair:
\begin{equation}
\label{eq:1}
\left[
xyz
\right]
abc
\end{equation}
Both my patch and Sašo's pull in excessive indentation between \left[
and \right]:
\left[
xyz
\right]
abc
In case of \left[ and \right., the excess persists after the pair:
\left[
xyz
\right.
abc
In both cases, "[" or "]" in comments can suppress the excess under
Sašo's patch.
>>>>> Sašo Živanović <saso.zivanovic@guest.arnes.si> writes:
> 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.
That seems reasonable direction: In comments, ignore {} while count []
(and other symbols?).
And it seems that AUCTeX should consider to indent inside [] only
optionally; by default it should indent inside {} only.
>>>>> Arash Esbati <arash@gnu.org> writes:
> Sašo Živanović <saso.zivanovic@guest.arnes.si> writes:
>> 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.
> I'm not sure, isn't this sort of overkill?
Hmm. There is enumeration style like
1) Item one.
2) This is two.
3) Foo bar.
, which will usually be realized in latex by
\renewcommand{\labelenumi}{\theenumi)~}
or
\usepackage{enumerate}
...
\begin{enumerate}[1)~]
. It can be distracting in such case to indent contents in ().
(In addition, some ASCII arts such as ":-)" and ":-(" can introduce
unmatched parens, braces and brackets in general.)
> (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!)
You are welcome. :-)
Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
- Re: Indenting the code written in square brackets as optional parameters, (continued)
- 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ć, 2022/03/09
- 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 <=
- 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
- Re: Indenting the code written in square brackets as optional parameters, Ikumi Keita, 2022/03/19
- Re: Indenting the code written in square brackets as optional parameters, Arash Esbati, 2022/03/19
- Re: Indenting the code written in square brackets as optional parameters, Ikumi Keita, 2022/03/20