Hi Keita,

Ikumi Keita <ik...@ikumi.que.jp> writes:

> I'd like to apply the attached fix for this issue. If no objection, I'll
> install it with some regression tests.

Thanks for your patch and sorry for my late response, which is not about
the patch which LGTM.

>>>>>> Ikumi Keita <ik...@ikumi.que.jp> writes:
>>
>> (2) There are customize options slightly related to the current topic,
>> namely `texmathp-allow-detached-args' and
>> `reftex-allow-detached-macro-args'. They both default to nil, so maybe
>> we should introduce a new customize option to do similar fine-control
>> over the behavior of `TeX-find-macro-boundaries' and
>> `TeX-find-macro-end-helper'.

I'm not sure if having a new custom option would help us; and reading
the section "2.6 Spacing and optional arguments" in usrguide.pdf tells
me that we can't get it right with the heuristics we're using.

>> (3) There are two packages related to the current topic:
>> The document of amsmath tells, with respect to \\[<dimension>] inside
>> display math environment, that
>> ,----
>> | Do not type a space between the \\ and the following [; only for display
>> | environments defined by amsmath the space is interpreted to mean that
>> | the bracketed material is part of the document content.
>> `----
>>[...]
>>
>> Thus if we are to be very strict, AUCTeX shouldn't consider separated
>> brackets as optional arguments for these cases. (I'm not sure whether
>> it's worth discriminating such strictly.)

Maybe we could handle control symbols differently in terms of: If there
is a bracket after the control symbol, take it as an optional argument,
otherwise not at all.  And we should really consider if that's worth the
effort.

Best, Arash

Reply via email to