Hi Paul, "Paul D. Nelson" <ultr...@gmail.com> writes:
> To treat such cases correctly, we could allow the signature (which with > the current version of the proposed patch can be an integer or pair of > integers, bounding the total or optional/required arguments) to be a > function. In TeX-find-macro-end-helper, we could call that function to > determine whether any additional arguments should be consumed, passing > along any arguments found thus far. We could assign the begin/end > macros a signature function that says "for \begin macros with > equation-like environments, don't accept any optional arguments". This > would allow meaningful folding of both examples, without the artifact > you have noted. On the other hand, it would require choosing good > defaults for which environments should not admit optional args, and I > don't have a clear sense there; do you? I think a function can be a good idea but I don't know what would be a good design in that case? Should we pass it some arguments? I guess not but a function without arguments would not be easiest to use. I guess it will have to rely on TeX-fold-macro-nth-arg. One alternative I can think of is to allow a function SPEC to return not only a string but also (STR . BOUND) where BOUND determines the extent of the folding. In the present case this would allow BOUND to determined by matching on the environment name and this pattern matching wouldn't have to be duplicated in the SPEC and SIG. > In my own setup, I do not fold equation environments, but instead use > prettification, as described in my earlier email. This serves as a > practical workaround. Before I adopted it, I remember encountering the > same issue you described and using workarounds such as adding a blank > commented line before the commutator bracket. I will try some more prettification the next time I mess with my config. Thanks for that idea. Rahguzar _______________________________________________ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
