GNU bug report logs - #61400
Different filling for verbatim macros

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61400 in the body.
You can then email your comments to 61400 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: auctex-bugs <bug-auctex <at> gnu.org>
Subject: Different filling for verbatim macros
Date: Fri, 10 Feb 2023 09:52:17 +0100

Hi all,

please set `TeX-parse-self' to t and load this small file:

--8<---------------cut here---------------start------------->8---
\documentclass{article}
\usepackage{url}
\usepackage{fvextra}

\begin{document}

Now we can write some text foo and \path{bar}

Now we can write some text foo and \path|bar|

Now we can write some text foo and \Verb|bar|

Now we can write some text foo and \Verb{bar}

Now we can write some text foo and \verb|bar|

\end{document}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% fill-column: 40
%%% End:
--8<---------------cut here---------------end--------------->8---

Now mark the five lines and hit 'M-q'.  I get:

--8<---------------cut here---------------start------------->8---
\documentclass{article}
\usepackage{url}
\usepackage{fvextra}

\begin{document}

Now we can write some text foo
and \path{bar}

Now we can write some text foo
and \path|bar|

Now we can write some text foo
and \Verb|bar|

Now we can write some text foo
and \Verb{bar}

Now we can write some text foo and
\verb|bar|

\end{document}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% fill-column: 40
%%% End:
--8<---------------cut here---------------end--------------->8---

Any idea what the reason is for the different break points?  This is
with Emacs 30 (emacs -Q) and latest AUCTeX from Git.

TIA.  Best, Arash

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Arash Esbati <arash <at> gnu.org>
Cc: bug-auctex <at> gnu.org, 61400 <at> debbugs.gnu.org
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Fri, 10 Feb 2023 10:23:41 +0100

Arash Esbati <arash <at> gnu.org> writes:

Hi Arash,

> \begin{document}
>
> Now we can write some text foo and \path{bar}
>
> Now we can write some text foo and \path|bar|
>
> Now we can write some text foo and \Verb|bar|
>
> Now we can write some text foo and \Verb{bar}
>
> Now we can write some text foo and \verb|bar|
>
> \end{document}

The different break point is already suggested when evaluating

  (LaTeX-fill-move-to-break-point (line-beginning-position))

at the end of each line.  So that function is where to start edebugging.

Bye,
Tassilo

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: bug-auctex <at> gnu.org, 61400 <at> debbugs.gnu.org
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Fri, 10 Feb 2023 10:47:24 +0100

Tassilo Horn <tsdh <at> gnu.org> writes:

> Arash Esbati <arash <at> gnu.org> writes:
>
>> \begin{document}
>>
>> Now we can write some text foo and \path{bar}
>>
>> Now we can write some text foo and \path|bar|
>>
>> Now we can write some text foo and \Verb|bar|
>>
>> Now we can write some text foo and \Verb{bar}
>>
>> Now we can write some text foo and \verb|bar|
>>
>> \end{document}
>
> The different break point is already suggested when evaluating
>
>   (LaTeX-fill-move-to-break-point (line-beginning-position))
>
> at the end of each line.  So that function is where to start edebugging.

Hi Tassilo,

thanks for pushing me into that again.  I did already but I missed
what's happening in that function directly in the first form:

  (fill-move-to-break-point linebeg)

It moves the point to different positions.  In the example above, put
point after \path{bar} and do:

  M-: (fill-move-to-break-point (line-beginning-position)) RET

and the point before and.  Now go after \verb|bar| and do the same, no
is point after and.  Can you reproduce this?

Best, Arash

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Arash Esbati <arash <at> gnu.org>
Cc: bug-auctex <at> gnu.org, 61400 <at> debbugs.gnu.org
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Fri, 10 Feb 2023 11:03:27 +0100

Arash Esbati <arash <at> gnu.org> writes:

> thanks for pushing me into that again.  I did already but I missed
> what's happening in that function directly in the first form:
>
>   (fill-move-to-break-point linebeg)
>
> It moves the point to different positions.  In the example above, put
> point after \path{bar} and do:
>
>   M-: (fill-move-to-break-point (line-beginning-position)) RET
>
> and the point before and.  Now go after \verb|bar| and do the same, no
> is point after and.  Can you reproduce this?

Yes, I can.  BTW, only the last sentence is broken correctly, all others
are wrapped around at a too early position.

Hm, (fill-nobreak-p) returns nil only on the \ of the \verb|bar| but
returns non-nil on each \ of the other verbatim macros.  (I can't look
any further now so it's your turn again. ;-))

Bye,
Tassilo

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: bug-auctex <at> gnu.org
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Fri, 10 Feb 2023 19:46:58 +0900

>>>>> Tassilo Horn <tsdh <at> gnu.org> writes:
>> It moves the point to different positions.  In the example above, put
>> point after \path{bar} and do:
>> 
>> M-: (fill-move-to-break-point (line-beginning-position)) RET
>> 
>> and the point before and.  Now go after \verb|bar| and do the same, no
>> is point after and.  Can you reproduce this?

> Yes, I can.

I can as well.

> Hm, (fill-nobreak-p) returns nil only on the \ of the \verb|bar| but
> returns non-nil on each \ of the other verbatim macros.  (I can't look
> any further now so it's your turn again. ;-))

I did repeated edebug and found that `LaTeX-verbatim-p' is the culprit.
When the point is just before \path{bar}, (LaTeX-verbatim-p) returns
non-nil and `fill-nobreak-bredicate' hook tells "Don't break here". On
the other hand, if the poinst is just before \verb|bar|,
(LaTeX-verbatim-p) returns nil.

Here is current definition of `LaTeX-verbatim-p':
,----
| (defun LaTeX-verbatim-p (&optional pos)
|   "Return non-nil if position POS is in a verbatim-like construct."
|   (when pos (goto-char pos))
|   (save-match-data
|     (or (progn
|           (syntax-propertize (point))
|           (nth 3 (syntax-ppss)))
|         (member (LaTeX-current-verbatim-macro)
|                 (LaTeX-verbatim-macros-with-delims))
|         (member (TeX-current-macro) (LaTeX-verbatim-macros-with-braces))
|         (member (LaTeX-current-environment) (LaTeX-verbatim-environments)))))
`----
After all, the difference comes from subtle difference between
`LaTeX-current-verbatim-macro' and `TeX-current-macro'. When the point
is just before the leading backslash, they returns:
                             | path  | verb  |
-----------------------------+-------+-------|
LaTeX-current-verbatim-macro | ""    | ""    |
TeX-current-macro            | "path"| "verb"|

In this context, it doesn't seem appropriate `TeX-current-macro' returns
non-nil.

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: bug-auctex <at> gnu.org, 61400 <at> debbugs.gnu.org
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Fri, 10 Feb 2023 12:41:12 +0100

Tassilo Horn <tsdh <at> gnu.org> writes:

> Yes, I can.  BTW, only the last sentence is broken correctly, all others
> are wrapped around at a too early position.

Thanks for checking.

> Hm, (fill-nobreak-p) returns nil only on the \ of the \verb|bar| but
> returns non-nil on each \ of the other verbatim macros.  (I can't look
> any further now so it's your turn again. ;-))

I think I've got it: `LaTeX-verbatim-p' does its job as a predicate, but
for filling, it should only return non-nil when point is inside the
argument, and not when point is in front of the \verb macro itself, this
is what `fill-move-to-break-point' does.  Try this file: Eval the forms
and then fill the other lines.

--8<---------------cut here---------------start------------->8---
\documentclass{article}
\usepackage{url}
\usepackage{fvextra}

\begin{document}

\begin{verbatim}
(defun LaTeX-verbatim-nobreak-p (&optional pos)
  "Return non-nil if position POS is in a verbatim-like construct."
  (when pos (goto-char pos))
  (save-match-data
    (or (progn
          (syntax-propertize (point))
          (nth 3 (syntax-ppss)))
        (member (LaTeX-current-verbatim-macro)
                (append
                 (LaTeX-verbatim-macros-with-delims)
                 (LaTeX-verbatim-macros-with-braces))))))

(setq-local fill-nobreak-predicate
            #'LaTeX-verbatim-nobreak-p)
\end{verbatim}

Now we can write some text foo and \path|bar|

Now we can write some text foo and \path|bar|

Now we can write some text foo and \Verb{bar}

Now we can write some text foo and \Verb|bar|

Now we can write some text foo and \verb|bar|

\end{document}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% fill-column: 40
%%% End:
--8<---------------cut here---------------end--------------->8---

Message #35 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Arash Esbati <arash <at> gnu.org>, Tassilo Horn <tsdh <at> gnu.org>
Cc: 61400 <at> debbugs.gnu.org
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Sat, 11 Feb 2023 17:55:52 +0900

Hi all,

>>>>> Arash Esbati <arash <at> gnu.org> writes:
> Tassilo Horn <tsdh <at> gnu.org> writes:
>> Hm, (fill-nobreak-p) returns nil only on the \ of the \verb|bar| but
>> returns non-nil on each \ of the other verbatim macros.  (I can't look
>> any further now so it's your turn again. ;-))

> I think I've got it: `LaTeX-verbatim-p' does its job as a predicate, but
> for filling, it should only return non-nil when point is inside the
> argument, and not when point is in front of the \verb macro itself, this
> is what `fill-move-to-break-point' does.

I realized that multiple players are involved in this issue. Let's see
how they interact:
Usually `LaTeX-verbatim-macro-boundaries' returns cons (BEG . END) where
BEG is the point just before the leading backslash of \verb etc.
However, there are inconsistencies when the point is at just before the
leading backslash; When "\verb..." is at beginning of a line, return
value is nil:

-!-\verb+abc+ ... (LaTeX-verbatim-macro-boundaries) -> nil

Otherwize, BEG is not the point just before the leading backslash, but
less than that value by 1:

xyz -!-\verb+abc+ ... (car (LaTeX-verbatim-macro-boundaries)) -> the
                       point just after the "z"

For this reason, `LaTeX-current-verbatim-macro' doesn't behave
consistently. It returns nil in the former case while the null string ""
in the latter.

-!-\verb+abc+     ... (LaTeX-current-verbatim-macro) -> nil
xyz -!-\verb+abc+ ... (LaTeX-current-verbatim-macro) -> ""

Here is the origin of the inconsistency.
----------------------------------------------------------------------
(defun LaTeX-verbatim-macro-boundaries ()
[...]
      ;; Search backwards for the macro start, unless we are facing one
      (unless (looking-at (concat (regexp-quote TeX-esc) verbatim-regexp)) --- (1)
        (catch 'found
          (while (progn
                   (skip-chars-backward (concat "^\n" (regexp-quote TeX-esc))
                                        (line-beginning-position))
                   (when (looking-at verbatim-regexp) (throw 'found nil)) --- (2)
                   (or (bobp) (forward-char -1))
                   (/= (point) (line-beginning-position))))))
      ;; Search forward for the macro end, unless we failed to find a start
      (unless (bolp)                                                    --- (3)
        (let* ((beg (1- (point)))
[...]
            (cons beg (1+ (point)))))))))
----------------------------------------------------------------------
When the point is just before the leading backslash, `looking-at' at (1)
matches and emacs skips to (3). But the block after (3) expects that the
point is just _after_ the leading backslash, as the rest of the code
exhibits. Actually, `looking-at' at (2) doesn't include backslash, so
emacs proceeds to (3) with the point at just _after_ the leading
backslash when (2) matches.

We can fix this inconsistency by the following code:
----------------------------------------------------------------------
(defun LaTeX-verbatim-macro-boundaries ()
[...]
      ;; Search backwards for the macro start, unless we are facing one
      (if (looking-at (concat (regexp-quote TeX-esc) verbatim-regexp))
          (forward-char 1)
        (catch 'found
[...]
----------------------------------------------------------------------
With this fix, `LaTeX-current-verbatim-macro' returns sane result even
when the point is just before "\verb". It just behave like
`TeX-current-macro'.

However, the story continues. With the above fix, Arash's original
example provides
Now we can write some text foo
and \path{bar}

Now we can write some text foo
and \path|bar|

Now we can write some text foo
and \Verb|bar|

Now we can write some text foo
and \Verb{bar}

Now we can write some text foo
and \verb|bar|

Yes, the behavior becomes coherent, but in the undesired direction. :-(

As Arash wrote, the reason is that `LaTeX-verbatim-p' returns non-nil
just before the leading backslashes for all these cases.
----------------------------------------------------------------------
(defun LaTeX-verbatim-p (&optional pos)
[...]
    (or (progn                                       --- (4)
          (syntax-propertize (point))                --- (4)
          (nth 3 (syntax-ppss)))                     --- (4)
        (member (LaTeX-current-verbatim-macro)                           --- (5)
                (LaTeX-verbatim-macros-with-delims))                     --- (5)
        (member (TeX-current-macro) (LaTeX-verbatim-macros-with-braces)) --- (5)
        (member (LaTeX-current-environment) (LaTeX-verbatim-environments)))))
----------------------------------------------------------------------
The block (4) returns nil when the point is just before the beginning of
quoted region. However, (5) returns non-nil when the point is just
before the verbatim macro. This isn't suitable for predicate of filling.

For consistency, maybe we should modify `TeX-current-macro' and
`LaTeX-current-verbatim-macro' so that they return nil when the point is
just before the verbatim macro. However, I'm not yet sure whether such
change brings about bad side effects.

Perhaps the safe fix is to tweak `TeX-current-macro' and
`LaTeX-current-verbatim-macro' so that they accept optional argument for
use in `LaTeX-verbatim-p'?

(By the way, 
        (member (LaTeX-current-verbatim-macro)
                (LaTeX-verbatim-macros-with-delims))
is a bit inefficient because `LaTeX-current-verbatim-macro' only
responds to macros included in `(LaTeX-verbatim-macros-with-delims)' for
the first place.)

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

Message #38 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 61400 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Sun, 12 Feb 2023 12:18:31 +0100

Hi Keita,

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

> I realized that multiple players are involved in this issue.

First of all, many thanks for your (as always) precise analysis 🙏🏿

> We can fix this inconsistency by the following code:
> ----------------------------------------------------------------------
> (defun LaTeX-verbatim-macro-boundaries ()
> [...]
>       ;; Search backwards for the macro start, unless we are facing one
>       (if (looking-at (concat (regexp-quote TeX-esc) verbatim-regexp))
>           (forward-char 1)
>         (catch 'found
> [...]
> ----------------------------------------------------------------------
> With this fix, `LaTeX-current-verbatim-macro' returns sane result even
> when the point is just before "\verb". It just behave like
> `TeX-current-macro'.

I think this should be our course of action: Make
`LaTeX-current-verbatim-macro' and `TeX-current-macro' work identical.

> Yes, the behavior becomes coherent, but in the undesired direction. :-(

We should take that.

> For consistency, maybe we should modify `TeX-current-macro' and
> `LaTeX-current-verbatim-macro' so that they return nil when the point is
> just before the verbatim macro. However, I'm not yet sure whether such
> change brings about bad side effects.

I agree, we shouldn't touch `TeX-current-macro'.

> Perhaps the safe fix is to tweak `TeX-current-macro' and
> `LaTeX-current-verbatim-macro' so that they accept optional argument for
> use in `LaTeX-verbatim-p'?

Here is another idea: We don't use `LaTeX-verbatim-p' in
`fill-nobreak-predicate', but define two new functions, say
`LaTeX-verbatim-macro-arg-boundaries' and `LaTeX-verbatim-nobreak-p'.
The first one is carved out of `LaTeX-verbatim-macro-boundaries' and
returns the beginning and end positions of the argument, as the name
suggests.

And `LaTeX-verbatim-nobreak-p' does the following: Check if the possible
break point for filling is inside the range returned by
`LaTeX-verbatim-macro-arg-boundaries' and if
`LaTeX-current-verbatim-macro' on that point returns non-nil, then
inhibit break there (t value), otherwise allow brake (nil value.)

WDYT, does this make sense?

Best, Arash

Message #41 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Arash Esbati <arash <at> gnu.org>
Cc: 61400 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Mon, 13 Feb 2023 00:32:06 +0900

[Message part 1 (text/plain, inline)]

Hi Arash and all,

>>>>> Arash Esbati <arash <at> gnu.org> writes:

> I think this should be our course of action: Make
> `LaTeX-current-verbatim-macro' and `TeX-current-macro' work identical.

I'm now thinking a different approach. Please see below.

> Here is another idea: We don't use `LaTeX-verbatim-p' in
> `fill-nobreak-predicate', but define two new functions, say
> `LaTeX-verbatim-macro-arg-boundaries' and `LaTeX-verbatim-nobreak-p'.
> The first one is carved out of `LaTeX-verbatim-macro-boundaries' and
> returns the beginning and end positions of the argument, as the name
> suggests.

> And `LaTeX-verbatim-nobreak-p' does the following: Check if the possible
> break point for filling is inside the range returned by
> `LaTeX-verbatim-macro-arg-boundaries' and if
> `LaTeX-current-verbatim-macro' on that point returns non-nil, then
> inhibit break there (t value), otherwise allow brake (nil value.)

> WDYT, does this make sense?

Looking at the current code closely, I think we can take a more drastic
route. :-)

(1) `LaTeX-current-verbatim-macro' is used only in
`LaTeX-verbatim-p':
,----
| > git grep -E LaTeX-current-verbatim-macro
| ChangeLog.1:    (LaTeX-current-verbatim-macro): Include asterisk, if present, in
| ChangeLog.1:    (LaTeX-verbatim-macro-boundaries, LaTeX-current-verbatim-macro)
| latex.el:(defun LaTeX-current-verbatim-macro ()
| latex.el:        (member (LaTeX-current-verbatim-macro)
`----
And `LaTeX-verbatim-macro-boundaries' is used only in
`LaTeX-current-verbatim-macro':
,----
| > git grep -E LaTeX-verbatim-macro-boundaries
| ChangeLog.1:    * latex.el (LaTeX-verbatim-macro-boundaries): Support verbatim
| ChangeLog.1:    * latex.el (LaTeX-verbatim-macro-boundaries): Do step backwards 
| at
| ChangeLog.1:    (LaTeX-verbatim-macro-boundaries): Find macro in case point is
| ChangeLog.1:    (LaTeX-verbatim-macro-boundaries, LaTeX-current-verbatim-macro)
| latex.el:(defun LaTeX-verbatim-macro-boundaries ()
| latex.el:  (let ((macro-boundaries (LaTeX-verbatim-macro-boundaries)))
`----

Those two functions are practically dedicated to `LaTeX-verbatim-p'.
Hence we can be rather flexible about what we do for them.

(2) `LaTeX-verbatim-p' is currently used only in
`fill-nobreak-predicate', `LaTeX-search-forward-comment-start' and
`TeX-in-comment' (through `TeX-verbatim-p-function'):
,----
| > git grep -E LaTeX-verbatim-p
| ChangeLog.1:    (LaTeX-verbatim-p): Doc fix.  Correct macro lookup.
| ChangeLog.1:    * style/verbatim.el (LaTeX-verbatim-package-options): New
| ChangeLog.1:    (LaTeX-verbatim-p, LaTeX-search-forward-comment-start): New
| latex.el:(defun LaTeX-verbatim-p (&optional pos)
| latex.el:                            (not (LaTeX-verbatim-p)))
| latex.el:               #'LaTeX-verbatim-p t)
| latex.el:  (setq TeX-verbatim-p-function #'LaTeX-verbatim-p)
| style/verbatim.el:(defvar LaTeX-verbatim-package-options nil
`----
Thus it's safe to modify `LaTeX-verbatim-p' to return nil at just before
"\verb|...|" etc. by the following reasons:
o In `LaTeX-search-forward-comment-start', `LaTeX-verbatim-p' is always
  called just before % sign.
o In `TeX-in-comment', `LaTeX-verbatim-p' is always called in a comment.

(3) I began to feel unsatisfied that `LaTeX-verbatim-p' needs the check
for `LaTeX-verbatim-macros-with-braces' in addition to
`LaTeX-current-verbatim-macro':
----------------------------------------------------------------------
(defun LaTeX-verbatim-p (&optional pos)
[...]
        (member (LaTeX-current-verbatim-macro)
                (LaTeX-verbatim-macros-with-delims))
        (member (TeX-current-macro) (LaTeX-verbatim-macros-with-braces)) <--- Here
        (member (LaTeX-current-environment) (LaTeX-verbatim-environments)))))
----------------------------------------------------------------------
Why can't `LaTeX-current-verbatim-macro' check both *-delims and
*-braces at the same time? Its name suggests it _should_ be able to
handle either type.

Looking at the contents of `LaTeX-verbatim-macro-boundaries', I came to
think that this is due to insufficient implementation:
----------------------------------------------------------------------
(defun LaTeX-verbatim-macro-boundaries ()
[...]
          ;; Heuristic: If an opening brace is encountered, search for
          ;; both the opening and the closing brace as an end marker.
          ;; Like that the function should work for \verb|...| as well
          ;; as for \url{...}.
          (when (string= delimiter TeX-grop)
            (setq delimiter (concat delimiter TeX-grcl)))
          (goto-char (1+ macro-end))
          (skip-chars-forward (concat "^" delimiter))
----------------------------------------------------------------------
This portion obviously indicates that this function is actually intended
for both *-delims and *-braces types of verbatim macros. Thus the line

          (verbatim-regexp (regexp-opt (LaTeX-verbatim-macros-with-delims) t)))

, a bit above the quoted portion, should actually include *-braces as
well. Then `LaTeX-verbatim-macro-boundaries' becomes able to handle both
*-delims and *-braces, and thus `LaTeX-current-verbatim-macro' does, too.

In addition, we don't have to keep the symmetric behavior of
`LaTeX-current-verbatim-macro' and `TeX-current-macro', given what I
wrote in (1). So we can modify `LaTeX-verbatim-macro-boundaries' so that
it returns nil at just before "\verb..." etc.

In this way, we can check both *-delims and *-braces by
`LaTeX-current-verbatim-macro' in `LaTeX-verbatim-p' without
`TeX-current-macro' like this:
----------------------------------------------------------------------
(defun LaTeX-verbatim-p (&optional pos)
[...]
    (or (progn
          (syntax-propertize (point))
          (nth 3 (syntax-ppss)))
        (LaTeX-current-verbatim-macro)
        (member (LaTeX-current-environment) (LaTeX-verbatim-environments)))))
----------------------------------------------------------------------

Actually, we can even omit `LaTeX-current-verbatim-macro' itself and use
`LaTeX-verbatim-macro-boundaries' instead:
----------------------------------------------------------------------
(defun LaTeX-verbatim-p (&optional pos)
[...]
    (or (progn
          (syntax-propertize (point))
          (nth 3 (syntax-ppss)))
        (LaTeX-verbatim-macro-boundaries)
        (member (LaTeX-current-environment) (LaTeX-verbatim-environments)))))
----------------------------------------------------------------------

(4) Actually, we usually need only
        (progn
          (syntax-propertize (point))
          (nth 3 (syntax-ppss)))
part in `LaTeX-verbatim-p' after all; the rest is fallback code for the
case that syntax propertize in font-latex.el wasn't used. (Unlike
`LaTeX-verbatim-macro-boundaries', `(nth 3 (syntax-ppss))' doesn't
return true on "\verb" macro itself; however it doesn't matter from what
I wrote in (2).)

Summing up the considerations above, I arrvied at the attached
tentative fix. I confirmed that it passes the regression tests.

What do you think about it?

(By the way, as written in the comment of the patch, I don't understand
the reason why the while loop in `LaTeX-verbatim-macro-boundaries' goes
back to the previous line. Is there any \verb variant, say in fancyverb
or fvextra, which allows newline in its argument?)

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

[patch (text/x-diff, inline)]

diff --git a/latex.el b/latex.el
index fb862b76..3b681b1f 100644
--- a/latex.el
+++ b/latex.el
@@ -3785,20 +3785,23 @@ values of the variable `LaTeX-verbatim-environments' as well.")
 Boundaries are returned as a cons cell where the car is the macro
 start and the cdr the macro end.
 
-Only macros which enclose their arguments with special
-non-parenthetical delimiters, like \\verb+foo+, are recognized."
+It doesn't regard the point just before \\verb... etc. belongs to
+the verbatim macro.  This isn't symmetric with
+`TeX-find-macro-boundaries'."
   (save-excursion
     (let ((orig (point))
-          (verbatim-regexp (regexp-opt (LaTeX-verbatim-macros-with-delims) t)))
-      ;; Search backwards for the macro start, unless we are facing one
-      (unless (looking-at (concat (regexp-quote TeX-esc) verbatim-regexp))
-        (catch 'found
-          (while (progn
-                   (skip-chars-backward (concat "^\n" (regexp-quote TeX-esc))
-                                        (line-beginning-position))
-                   (when (looking-at verbatim-regexp) (throw 'found nil))
-                   (or (bobp) (forward-char -1))
-                   (/= (point) (line-beginning-position))))))
+          (verbatim-regexp (regexp-opt
+                            (append (LaTeX-verbatim-macros-with-delims)
+                                    (LaTeX-verbatim-macros-with-braces))
+                            t)))
+      (catch 'found
+        (while (progn
+                 (skip-chars-backward (concat "^" (regexp-quote TeX-esc))
+                                      (line-beginning-position))
+                 (when (looking-at verbatim-regexp) (throw 'found nil))
+                 ;; XXX: Why do we go back to the preceding lines?
+                 (or (bobp) (forward-char -1))
+                 (not (bolp)))))
       ;; Search forward for the macro end, unless we failed to find a start
       (unless (bolp)
         (let* ((beg (1- (point)))
@@ -3820,27 +3823,27 @@ non-parenthetical delimiters, like \\verb+foo+, are recognized."
           (when (<= orig (point))
             (cons beg (1+ (point)))))))))
 
-(defun LaTeX-current-verbatim-macro ()
-  "Return name of verbatim macro containing point, nil if none is present."
-  (let ((macro-boundaries (LaTeX-verbatim-macro-boundaries)))
-    (when macro-boundaries
-      (save-excursion
-        (goto-char (car macro-boundaries))
-        (forward-char (length TeX-esc))
-        (buffer-substring-no-properties
-         (point) (progn (skip-chars-forward "@A-Za-z*") (point)))))))
+;; (defun LaTeX-current-verbatim-macro ()
+;;   "Return name of verbatim macro containing point, nil if none is present."
+;;   (let ((macro-boundaries (LaTeX-verbatim-macro-boundaries)))
+;;     (when macro-boundaries
+;;       (save-excursion
+;;         (goto-char (car macro-boundaries))
+;;         (forward-char (length TeX-esc))
+;;         (buffer-substring-no-properties
+;;          (point) (progn (skip-chars-forward "@A-Za-z*") (point)))))))
 
 (defun LaTeX-verbatim-p (&optional pos)
   "Return non-nil if position POS is in a verbatim-like construct."
   (when pos (goto-char pos))
   (save-match-data
-    (or (progn
+    (if (eq TeX-install-font-lock 'font-latex-setup)
+        (progn
           (syntax-propertize (point))
           (nth 3 (syntax-ppss)))
-        (member (LaTeX-current-verbatim-macro)
-                (LaTeX-verbatim-macros-with-delims))
-        (member (TeX-current-macro) (LaTeX-verbatim-macros-with-braces))
-        (member (LaTeX-current-environment) (LaTeX-verbatim-environments)))))
+      (or
+       (LaTeX-verbatim-macro-boundaries)
+       (member (LaTeX-current-environment) (LaTeX-verbatim-environments))))))
 
 
 ;;; Formatting

Message #44 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: 61400 <at> debbugs.gnu.org
Cc: Arash Esbati <arash <at> gnu.org>, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Mon, 13 Feb 2023 14:34:39 +0900

Following up myself.

>>>>> Ikumi Keita <ikumi <at> ikumi.que.jp> writes:
> (2) `LaTeX-verbatim-p' is currently used only in
> `fill-nobreak-predicate', `LaTeX-search-forward-comment-start' and
> `TeX-in-comment' (through `TeX-verbatim-p-function'):

Sorry, there is another instance of usage in `TeX-insert-dollar'. That
is safe for the proposed change for `LaTeX-verbatim-p', too.

> (By the way, as written in the comment of the patch, I don't understand
> the reason why the while loop in `LaTeX-verbatim-macro-boundaries' goes
> back to the previous line. Is there any \verb variant, say in fancyverb
> or fvextra, which allows newline in its argument?)

I misunderstood the role of `(forward-char -1)'. (^_^;) It passes over
the backslash. Going back to the previous line is just an unintentional
side effect, `(bobp)' in front of `(forward-char -1)' should actually be
`(bolp)'.

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

Message #47 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 61400 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Mon, 13 Feb 2023 12:07:59 +0100

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

> Looking at the current code closely, I think we can take a more drastic
> route. :-)

That's always highly welcome :-)

> Thus it's safe to modify `LaTeX-verbatim-p' to return nil at just before
> "\verb|...|" etc. by the following reasons:
> o In `LaTeX-search-forward-comment-start', `LaTeX-verbatim-p' is always
>   called just before % sign.
> o In `TeX-in-comment', `LaTeX-verbatim-p' is always called in a comment.

Do we really want this?  My gut feeling is to have `LaTeX-verbatim-p'
returns t just before the "\verb|...|" etc., i.e., when cursor is over
the backslash.

> (3) I began to feel unsatisfied that `LaTeX-verbatim-p' needs the check
> for `LaTeX-verbatim-macros-with-braces' in addition to
> `LaTeX-current-verbatim-macro':
> ----------------------------------------------------------------------
> (defun LaTeX-verbatim-p (&optional pos)
> [...]
>         (member (LaTeX-current-verbatim-macro)
>                 (LaTeX-verbatim-macros-with-delims))
>         (member (TeX-current-macro) (LaTeX-verbatim-macros-with-braces)) <--- Here
>         (member (LaTeX-current-environment) (LaTeX-verbatim-environments)))))
> ----------------------------------------------------------------------
> Why can't `LaTeX-current-verbatim-macro' check both *-delims and
> *-braces at the same time? Its name suggests it _should_ be able to
> handle either type.

This was also my takeaway after reading the code.

> In addition, we don't have to keep the symmetric behavior of
> `LaTeX-current-verbatim-macro' and `TeX-current-macro', given what I
> wrote in (1). So we can modify `LaTeX-verbatim-macro-boundaries' so that
> it returns nil at just before "\verb..." etc.

See above, my thinking is if it will be more future proof the other way
around.

> Summing up the considerations above, I arrvied at the attached
> tentative fix. I confirmed that it passes the regression tests.
>
> What do you think about it?

Thanks, LGTM.  One other complication we have to deal with is that \Verb
from fancyvrb or \lstinline from listings can have an optional argument,
e.g.:

  \Verb[fontsize=\scriptsize]|foo bar|

The following change to your suggestion should work:

--8<---------------cut here---------------start------------->8---
(defun LaTeX-verbatim-macro-boundaries ()
  "Return boundaries of verbatim macro.
Boundaries are returned as a cons cell where the car is the macro
start and the cdr the macro end.

It doesn't regard the point just before \\verb... etc. belongs to
the verbatim macro.  This isn't symmetric with
`TeX-find-macro-boundaries'."
  (save-excursion
    (let ((orig (point))
          (verbatim-regexp (regexp-opt
                            (append (LaTeX-verbatim-macros-with-delims)
                                    (LaTeX-verbatim-macros-with-braces))
                            t)))
      (catch 'found
        (while (progn
                 (skip-chars-backward (concat "^" (regexp-quote TeX-esc))
                                      (line-beginning-position))
                 (when (looking-at verbatim-regexp) (throw 'found nil))
                 ;; XXX: Why do we go back to the preceding lines?
                 (or (bobp) (forward-char -1))
                 (not (bolp)))))
      ;; Search forward for the macro end, unless we failed to find a start
      (unless (bolp)
        (let* ((beg (1- (point)))
               (macro-end (match-end 0))
               ;; -- NEW
               opt-end
               ;; -- CHANGED
               ;; 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.
               ;; Besides, \lstinline or \Verb (from fancyvrb) also
               ;; accept an optional argument which we have to
               ;; encounter.  We assume that users don't write
               ;; something like this '\Verb[foo[' and again the
               ;; delimiter is directly after the ] closing the
               ;; optional argument:
               ;; -- CHANGED
               (delimiter (if (= (char-after macro-end) ?\[)
                              (save-excursion (goto-char macro-end)
                                              (forward-list)
                                              (setq opt-end (point))
                                              (string (following-char)))
                            (buffer-substring-no-properties
                             macro-end (1+ macro-end)))))
          ;; Heuristic: If an opening brace is encountered, search for
          ;; both the opening and the closing brace as an end marker.
          ;; Like that the function should work for \verb|...| as well
          ;; as for \url{...}.
          (when (string= delimiter TeX-grop)
            (setq delimiter (concat delimiter TeX-grcl)))
          ;; -- CHANGED
          (if opt-end
              (goto-char (1+ opt-end))
            (goto-char (1+ macro-end)))
          (skip-chars-forward (concat "^" delimiter))
          (when (<= orig (point))
            (cons beg (1+ (point)))))))))
--8<---------------cut here---------------end--------------->8---

And while we're at it: The docstring isn't correct any more, right?  I
mean this part:

    It doesn't regard the point just before \\verb... etc. belongs to
    the verbatim macro.  This isn't symmetric with
    `TeX-find-macro-boundaries'.

> (By the way, as written in the comment of the patch, I don't understand
> the reason why the while loop in `LaTeX-verbatim-macro-boundaries' goes
> back to the previous line. Is there any \verb variant, say in fancyverb
> or fvextra, which allows newline in its argument?)

No, not that I'm aware of; linebreak in verb arg is a no-no.

> +;; (defun LaTeX-current-verbatim-macro ()
> +;;   "Return name of verbatim macro containing point, nil if none is present."
> +;;   (let ((macro-boundaries (LaTeX-verbatim-macro-boundaries)))
> +;;     (when macro-boundaries
> +;;       (save-excursion
> +;;         (goto-char (car macro-boundaries))
> +;;         (forward-char (length TeX-esc))
> +;;         (buffer-substring-no-properties
> +;;          (point) (progn (skip-chars-forward "@A-Za-z*") (point)))))))

Would it make sense to keep the above as a utility function?

Best, Arash

Message #50 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Arash Esbati <arash <at> gnu.org>
Cc: 61400 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Tue, 14 Feb 2023 15:46:53 +0900

[Message part 1 (text/plain, inline)]

Hi Arash,

>>>>> Arash Esbati <arash <at> gnu.org> writes:
> Do we really want this?  My gut feeling is to have `LaTeX-verbatim-p'
> returns t just before the "\verb|...|" etc., i.e., when cursor is over
> the backslash.

OK, then another candidate is the attached patch. This keeps the current
behavior of `LaTeX-verbatim-p' and introduces a new function
`LaTeX-verbatim-nobreak-p' as you suggested in your previous message.

However, I'm a bit reluctant.
1. If `LaTeX-verbatim-p' should return non-nil at just before
   "\verb", then it should also do so just before "\begin{verbatim}" for
   consistency, shouldn't it?
2. Suppose that you type "$" just before "\verb...". Then
   `TeX-insert-dollar' inserts only one "$" instead of "$$" under the
   current behavior of `LaTeX-verbatim-p', because `TeX-insert-dollar'
   uses `TeX-verbatim-p'. I think it's unexpected. 

> Thanks, LGTM.  One other complication we have to deal with is that \Verb
> from fancyvrb or \lstinline from listings can have an optional argument,
> e.g.:

>   \Verb[fontsize=\scriptsize]|foo bar|

Thanks, I incorporated it with slight modification in the attached patch.

>> +;; (defun LaTeX-current-verbatim-macro ()
>> +;;   "Return name of verbatim macro containing point, nil if none is present."
>> +;;   (let ((macro-boundaries (LaTeX-verbatim-macro-boundaries)))
>> +;;     (when macro-boundaries
>> +;;       (save-excursion
>> +;;         (goto-char (car macro-boundaries))
>> +;;         (forward-char (length TeX-esc))
>> +;;         (buffer-substring-no-properties
>> +;;          (point) (progn (skip-chars-forward "@A-Za-z*") (point)))))))

> Would it make sense to keep the above as a utility function?

This time I leave that function as is.

> And while we're at it: The docstring isn't correct any more, right?  I
> mean this part:

>     It doesn't regard the point just before \\verb... etc. belongs to
>     the verbatim macro.  This isn't symmetric with
>     `TeX-find-macro-boundaries'.

In my previous patch, it's correct because I removed the chunk
      (if (looking-at (concat (regexp-quote TeX-esc) verbatim-regexp))
          (forward-char 1)
from `LaTeX-verbatim-macro-boundaries'. :-)

(By the way, I noticed that `LaTeX-verbatim-p' raises error when "\verb"
is at the end of the buffer without delimiters and its contents "|...|".
In fact `LaTeX-verbatim-macro-boundaries' and
`LaTeX-current-verbatim-macro' raise the same error. The reason is that
`LaTeX-verbatim-macro-boundaries' presumes there is nonempty string
after the macro body. Should we cater for such corner case?)

Best,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

[patch (text/x-diff, attachment)]

Message #53 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 61400 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Tue, 14 Feb 2023 11:30:13 +0100

[Message part 1 (text/plain, inline)]

Hi Keita,

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

> OK, then another candidate is the attached patch.

Thanks.

> This keeps the current behavior of `LaTeX-verbatim-p' and introduces a
> new function `LaTeX-verbatim-nobreak-p' as you suggested in your
> previous message.
>
> However, I'm a bit reluctant.
> 1. If `LaTeX-verbatim-p' should return non-nil at just before
>    "\verb", then it should also do so just before "\begin{verbatim}" for
>    consistency, shouldn't it?
> 2. Suppose that you type "$" just before "\verb...". Then
>    `TeX-insert-dollar' inserts only one "$" instead of "$$" under the
>    current behavior of `LaTeX-verbatim-p', because `TeX-insert-dollar'
>    uses `TeX-verbatim-p'. I think it's unexpected. 

I think we have everything we need now so we can change the behavior of
`LaTeX-verbatim-p' acc. to what you describe above because:

 • `LaTeX-verbatim-macro-boundaries' returns the inner (nice!) and outer
   boundries of a macro, incl. the backslash
 • `LaTeX-current-verbatim-macro' returns the name of the macro

So one can extract all the information needed.

> Thanks, I incorporated it with slight modification in the attached
> patch.

🙏

> In my previous patch, it's correct because I removed the chunk
>       (if (looking-at (concat (regexp-quote TeX-esc) verbatim-regexp))
>           (forward-char 1)
> from `LaTeX-verbatim-macro-boundaries'. :-)

Ok.

Note that I had to apply the patch attached on top of yours in order to
get it working (some trouble with parens).  I've also adjusted the
comment (the optional arg of \lstinline was already there).  And also I
changed

  (delimiter (if (= (char-after end) ?\[)

to

  (delimiter (if (string= (string (char-after end)) LaTeX-optop)

in case that character changes.

> (By the way, I noticed that `LaTeX-verbatim-p' raises error when "\verb"
> is at the end of the buffer without delimiters and its contents "|...|".
> In fact `LaTeX-verbatim-macro-boundaries' and
> `LaTeX-current-verbatim-macro' raise the same error. The reason is that
> `LaTeX-verbatim-macro-boundaries' presumes there is nonempty string
> after the macro body. Should we cater for such corner case?)

I'd say let's fix the issue at hand and then see if others complain and
there is a real use for this corner case, and then we can touch that.
Does it make sense?

Best, Arash

[patchpatch (application/octet-stream, attachment)]

Message #56 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Arash Esbati <arash <at> gnu.org>
Cc: 61400 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Wed, 15 Feb 2023 15:30:52 +0900

Hi Arash,

>>>>> Arash Esbati <arash <at> gnu.org> writes:
>> However, I'm a bit reluctant.
>> 1. If `LaTeX-verbatim-p' should return non-nil at just before
>> "\verb", then it should also do so just before "\begin{verbatim}" for
>> consistency, shouldn't it?
>> 2. Suppose that you type "$" just before "\verb...". Then
>> `TeX-insert-dollar' inserts only one "$" instead of "$$" under the
>> current behavior of `LaTeX-verbatim-p', because `TeX-insert-dollar'
>> uses `TeX-verbatim-p'. I think it's unexpected. 
>
> I think we have everything we need now so we can change the behavior of
> `LaTeX-verbatim-p' acc. to what you describe above because:

Sorry, I'm unsure what you mean by "to what you describe above".
1. To change `LaTeX-verbatim-p' to return non-nil just before
   "\begin{verbatim}", keeping the current behavior at just before
   "\verb..."?
2. To change `LaTeX-verbatim-p' to return nil just before "\verb..."?

Reading again my paragraphs, my opinion wasn't clear enough probably. I
feel that it isn't natural that `LaTeX-verbatim-p' returns non-nil just
before "\begin{verbatim}". Taking into account `TeX-insert-dollar'
behavior as well, I'm still in favor of changing it to return nil just
before "\verb..." as my first patch, keeping the current behavior just
before "\begin{verbatim}". That's the reason why I feel reluctant.

> Note that I had to apply the patch attached on top of yours in order
> to get it working (some trouble with parens). I've also adjusted the
> comment (the optional arg of \lstinline was already there).

Oops, sorry for those! 😵

>> (By the way, I noticed that `LaTeX-verbatim-p' raises error when "\verb"
>> is at the end of the buffer without delimiters and its contents "|...|".
>> In fact `LaTeX-verbatim-macro-boundaries' and
>> `LaTeX-current-verbatim-macro' raise the same error. The reason is that
>> `LaTeX-verbatim-macro-boundaries' presumes there is nonempty string
>> after the macro body. Should we cater for such corner case?)

> I'd say let's fix the issue at hand and then see if others complain and
> there is a real use for this corner case, and then we can touch that.
> Does it make sense?

I see, let's do so.

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

Message #59 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 61400 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Wed, 15 Feb 2023 09:37:42 +0100

Hi Keita,

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

> Taking into account `TeX-insert-dollar' behavior as well, I'm still in
> favor of changing it to return nil just before "\verb..." as my first
> patch, keeping the current behavior just before "\begin{verbatim}".

Sorry for the confusion.  I wanted to say that I like your suggestion
above, let's take this route :-)

Best, Arash

Message #62 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Arash Esbati <arash <at> gnu.org>
Cc: 61400 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Wed, 15 Feb 2023 20:29:52 +0900

[Message part 1 (text/plain, inline)]

Hi Arash,

>>>>> Arash Esbati <arash <at> gnu.org> writes:
> Sorry for the confusion.  I wanted to say that I like your suggestion
> above, let's take this route :-)

Thanks, now I'd like to push the attached commit. Any comments welcome.

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

[0001-Fill-verb-like-macros-appropriately-bug-61400.patch (text/x-diff, attachment)]

Message #65 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 61400 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Wed, 15 Feb 2023 18:36:44 +0100

Hi Keita,

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

> Thanks, now I'd like to push the attached commit. Any comments welcome.

Thanks, I think I have one minor comment.  Take this example:

--8<---------------cut here---------------start------------->8---
\documentclass{article}

\usepackage{fvextra}

\begin{document}
\Verb{pre\cmd{test}p*st}
\end{document}
--8<---------------cut here---------------end--------------->8---

Put point on * and try

  M-: (LaTeX-verbatim-macro-boundaries) RET

which returns nil.  This is due to this part of the function:

  (when (string= delimiter TeX-grop)
    (setq delimiter (concat delimiter TeX-grcl)))
  (goto-char (1+ end))
  (skip-chars-forward (concat "^" delimiter))

What I don't understand it why the code does:

  (when (string= delimiter TeX-grop)
    (setq delimiter (concat delimiter TeX-grcl)))

which is "^{}"; I would have expected "^}" only because using \verb{foo{
is just asking for trouble and not officially supported IIRC.  Even with
delimiter being "^}", this form:

  (skip-chars-forward (concat "^" delimiter))

means stop before the first "}" which is not far enough in case we have
balanced braces in the argument (and only such are allowed).  So I
suggest we change this part of the code like this:

--8<---------------cut here---------------start------------->8---
diff --git a/latex.el b/latex.el
index 03795cf4..bbb8cd29 100644
--- a/latex.el
+++ b/latex.el
@@ -3830,10 +3830,14 @@ of the macro argument as cons."
           ;; both the opening and the closing brace as an end marker.
           ;; Like that the function should work for \verb|...| as well
           ;; as for \url{...}.
-          (when (string= delimiter TeX-grop)
-            (setq delimiter (concat delimiter TeX-grcl)))
-          (goto-char (1+ end))
-          (skip-chars-forward (concat "^" delimiter))
+          (if (string= delimiter TeX-grop)
+              (progn
+                (goto-char end)
+                (re-search-forward "{[^}{]*\\(?:{[^}{]*}[^}{]*\\)*}"
+                                   (line-end-position) t)
+                (backward-char))
+            (goto-char (1+ end))
+            (skip-chars-forward (concat "^" delimiter)))
           (when (<= orig (point))
             (if arg-only
                 (cons (1+ end) (point))
--8<---------------cut here---------------end--------------->8---

Then we only need to solve the fontification issue ;-)  WDYT?

Best, Arash

Message #68 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Arash Esbati <arash <at> gnu.org>
Cc: 61400 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Thu, 16 Feb 2023 17:55:32 +0900

[Message part 1 (text/plain, inline)]

Hi Arash,

>>>>> Arash Esbati <arash <at> gnu.org> writes:
> What I don't understand it why the code does:

>   (when (string= delimiter TeX-grop)
>     (setq delimiter (concat delimiter TeX-grcl)))

> which is "^{}"; I would have expected "^}" only because using \verb{foo{
> is just asking for trouble and not officially supported IIRC.

That's what I was wondering too.

> Even with delimiter being "^}", this form:

>   (skip-chars-forward (concat "^" delimiter))

> means stop before the first "}" which is not far enough in case we have
> balanced braces in the argument (and only such are allowed).  So I
> suggest we change this part of the code like this:
[...]
> Then we only need to solve the fontification issue ;-)  WDYT?

Thanks, I included your suggestion. See the attachment.

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

[0001-Fill-verb-like-macros-appropriately-bug-61400.patch (text/x-diff, attachment)]

Message #71 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 61400 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Thu, 16 Feb 2023 10:34:48 +0100

Hi Keita,

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

> Thanks, I included your suggestion. See the attachment.

LGTM.  Please go ahead and install so we can close this report.  Please
just adjust the comment below before pushing:

>            ;; Heuristic: If an opening brace is encountered, search for
>            ;; both the opening and the closing brace as an end marker.

I think now this should read:

            ;; Heuristic: If an opening brace is encountered, search for
            ;; a closing brace as an end marker.

Thanks for working on this.

Best, Arash

Message #74 received at 61400 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Arash Esbati <arash <at> gnu.org>
Cc: 61400 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Thu, 16 Feb 2023 21:04:53 +0900

Hi Arash,

>>>>> Arash Esbati <arash <at> gnu.org> writes:
> LGTM.  Please go ahead and install so we can close this report.  Please
> just adjust the comment below before pushing:

>> ;; Heuristic: If an opening brace is encountered, search for
>> ;; both the opening and the closing brace as an end marker.

> I think now this should read:

>             ;; Heuristic: If an opening brace is encountered, search for
>             ;; a closing brace as an end marker.

Done. I also changed
            (skip-chars-forward (concat "^" delimiter)))
to
            (skip-chars-forward (concat "^" delimiter) (line-end-position)))
, which isn't important much. (It makes difference only when closing
delimiter is missing. In that case, the function doesn't return sensible
result anyway.)

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

Message #79 received at 61400-done <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 61400-done <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#61400: Different filling for verbatim macros
Date: Thu, 16 Feb 2023 13:50:13 +0100

Hi Keita,

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

> Done. I also changed
>             (skip-chars-forward (concat "^" delimiter)))
> to
>             (skip-chars-forward (concat "^" delimiter) (line-end-position)))

many thanks for fixing this issue.  I'm therefore closing this report.

Best, Arash

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.