[Top][All Lists]

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

bug#51762: 13.0.14; environment formating

From: Pierre L. Nageoire
Subject: bug#51762: 13.0.14; environment formating
Date: Sat, 20 Nov 2021 09:50:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)


Anyway thanks having taken care of this question ! I hope you ll find a
good solution ; I have unfortunately no time to investigate this subtle
regexp question. Moreover I am not familiar with this part of auctex

So thanks again to do it for me and hopefully for the rest of the
community !

Arash Esbati <arash@gnu.org> writes:

> 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

reply via email to

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