bug#51762: 13.0.14; environment formating

[Ikumi Keita]

>>>>> Arash Esbati <arash@gnu.org> writes:
>>> 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.

Indeed.

>> 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?

First of all, my previous propoal doesn't work correctly for lines
ending with "\par". The first regexp group in the current code spans the
highlighted interval in the attached screenshot actually, so the
criterion "(not (match-beginning 0))" in the previous proposal is wrong.
I attach the revised patch at last of this message.

> Do you have an idea about the performance hit?

Unfortunatetly, no. I just tried several examples by hand and checked
that "make check" passes. They worked smoothly so I expect there isn't
serious performance problem.

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

OMG! 😖

Anyway, I'd like to commit the attached revised fix along with some
additional regression tests if no one objects.

Regards,
Ikumi Keita

screenshot.png
Description: regexp group coverage

patch
Description: revised patch