[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) |
Hi,
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
code.
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
- bug#51762: 13.0.14; environment formating, (continued)
- bug#51762: 13.0.14; environment formating, Ikumi Keita, 2021/11/14
- bug#51762: 13.0.14; environment formating, Arash Esbati, 2021/11/15
- bug#51762: 13.0.14; environment formating, Ikumi Keita, 2021/11/16
- bug#51762: 13.0.14; environment formating, Arash Esbati, 2021/11/17
- bug#51762: 13.0.14; environment formating, Ikumi Keita, 2021/11/17
- bug#51762: 13.0.14; environment formating, Ikumi Keita, 2021/11/18
- bug#51762: 13.0.14; environment formating, Ikumi Keita, 2021/11/18
- bug#51762: 13.0.14; environment formating, Arash Esbati, 2021/11/18
- bug#51762: 13.0.14; environment formating, Ikumi Keita, 2021/11/18
- bug#51762: 13.0.14; environment formating, Arash Esbati, 2021/11/19
- bug#51762: 13.0.14; environment formating,
Pierre L. Nageoire <=