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 <ar...@gnu.org> writes: > Hi Keita, > > Ikumi Keita <ik...@ikumi.que.jp> writes: > >>>>>>> Arash Esbati <ar...@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-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex