auctex-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch for possible bug in TeX-find-macro-end-helper


From: Ikumi Keita
Subject: Re: Patch for possible bug in TeX-find-macro-end-helper
Date: Fri, 06 Jan 2023 16:24:57 +0900

Hi all,

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

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

Attachment: 0001-Support-detached-arguments.patch
Description: patch

>>>>> Ikumi Keita <ikumi@ikumi.que.jp> writes:
> Hi Enrico,
>>>>> Enrico Flor <enrico@eflor.net> writes:

>> Here are the positions where point lands after evaluating

>> (goto-char (TeX-find-macro-end-helper))

>> with point at the beginning of the macro:

>> \macro{first}
>> {second}█

>> \macro{first}█
>> {second}

>> \macro{first} % comment
>> {second}█

>> What happens is that whitespace in the second line is skipped only if
>> the previous line ended with some comment.  Since "second" is parsed as
>> the second argument of the macro in all three cases, I think
>> TeX-find-macro-end-helper should return the position right after
>> `{second}` in all three cases.  If this is correct, this patch should
>> implement the behavior (it just modifies two regexps in that function).

> Indeed. (The form to evaluate should actually be
>   (goto-char (TeX-find-macro-end-helper (point)))
> , but that doesn't matter much.)

>> Please forgive the noise if this is in fact an intentional behavior.

> I suppose that the reported difference is just accidental one without
> any particular intention. So I think AUCTeX can accept your patch.

> Here are some related thoughts:
> (1) The former half of `TeX-find-macro-boundaries' has similar subtle
> inconsistency. When I evaluate
> (let (start-point)
>         (save-excursion
>           (catch 'abort
>             (let ((parse-sexp-ignore-comments t))
>               (when (condition-case nil (progn (up-list) t) (error nil))
>                 (while (progn
>                          (condition-case nil (backward-sexp)
>                            (error (throw 'abort nil)))
>                          (forward-comment -1)
>                          (and (memq (char-before) '(?\] ?\}))
>                               (not (TeX-escaped-p (1- (point)))))))
>                 (skip-chars-backward "A-Za-z@*")
>                 (when (and (eq (char-before) (aref TeX-esc 0))
>                            (not (TeX-escaped-p (1- (point)))))
>                   (setq start-point (1- (point))))))))
>         (goto-char start-point))
> inside the "{second}" in the following examples, the third one leads to
> error caused by `(goto-char nil)'.

> \macro{first}
> {second}

> \macro{first}
>   {second}

> \macro{first} % comment
>   {second}

> \macro{first}% comment
>   {second}

> Thus I think `TeX-find-macro-boundaries' should be fixed as well.

> (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'.

> (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.
> `----

> The document of mathtools says that it allows users to write
> \[
>   \begin{gathered}
>     [t] = 100 \\
>     [v] = 200
>   \end{gathered}
> \]
> where [t] isn't interpreted as an optional argument for gathered
> environment. (This is package default behavior; "allowspaces" package
> option can disable it.)

> 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.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]