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