bug#51762: 13.0.14; environment formating

[Arash Esbati]

Hi Keita,

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

>>>>>> Arash Esbati <arash@gnu.org> writes:
>> Thank you for looking into this.  The way I understand this regexp:
>
>>   "\\([^ \r\n%\\]\\|\\\\%\\)\\([ \t]\\|\\\\\\\\\\)*"
>>                     ^^^^^^^
>
>> is there to exclude the control symbol \%, i.e., being parsed as comment
>> start.
>
> I think so, too. Tassilo added it to fix bug#48937 this June.
>
>> Would it help if we generlize the control symbol idea by saying:
>
>>   "\\([^ \r\n%\\]\\|\\\\[^a-zA-Z0-9\\]\\)\\([ \t]\\|\\\\\\\\\\)*"
>>                         ^^^^^^^^^^^^^^
>
> I'm afraid that it doesn't match a line
>  \\% This is a code comment.
> , either. Try typing M-q on the following paragraph in latex mode
> buffer:
> ----------------------------------------------------------------------
> Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit
> tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et,
>  \\% This is a code comment.
> mattis eget, convallis nec, purus.
> ----------------------------------------------------------------------

I agree; it's hard to come up with a regexp to catch all possible
comment lines.

>>> Maybe we should give up regexp-based approach to find out code comments
>>> accurately.
>
>> Are you thinking about `syntax-ppss'?
>
> No, other parts of latex.el ideintify code comments by a different logic
> like:
>        ;; A line with some code, followed by a comment?
>        ((and (setq code-comment-start (save-excursion
>                                         (beginning-of-line)
>                                         (TeX-search-forward-comment-start
>                                          (line-end-position))))
>              (> (point) code-comment-start)
>              (not (TeX-in-commented-line))
>              (save-excursion
>                (goto-char code-comment-start)
>                ;; See if there is at least one non-whitespace character
>                ;; before the comment starts.
>                (re-search-backward "[^ \t\n]" (line-beginning-position) t)))
>
> So it would be better to follow this logic than to rely on regexp. In
> addition, regexp-based approach is easily fooled by percent sign in
> \verb, while `TeX-search-forward-comment-start' (which in turn calls
> `LaTeX-search-forward-comment-start') takes care of such cases.
>
> I ended up with the attached tentative patch. I hope this doesn't slow
> down the filling loop significantly. What do you think about it?

Do you have an idea about the performance hit?  I'd say we have to bite
the bullet and use the code.  Our current approach is not the best.  And
while we're at it, we'll have to take care of this comment in
`LaTeX-verbatim-macro-boundaries':

    ;; XXX: Here we assume we are dealing with \verb which
    ;; expects the delimiter right behind the command.
    ;; However, \lstinline can also cope with whitespace as
    ;; well as an optional argument after the command.

Other packages like fancyvrb and minted do the same: Inline verb macros
can have an optional and a mandatory argument.  So the regexp fun will
continue :-)

Best, Arash