branch master updated: * tp/Texinfo/ParserNonXS.pm (_process_remaining_on_line), tp/Texinfo/XS/parsetexi/parser.c (process_remaining_on_line): explain why the next input is directly drawn after macro handling.

[Patrice Dumas]

This is an automated email from the git hooks/post-receive script.

pertusus pushed a commit to branch master
in repository texinfo.

The following commit(s) were added to refs/heads/master by this push:
     new d38cacec17 * tp/Texinfo/ParserNonXS.pm (_process_remaining_on_line), 
tp/Texinfo/XS/parsetexi/parser.c (process_remaining_on_line): explain why the 
next input is directly drawn after macro handling.
d38cacec17 is described below

commit d38cacec17904d4e6ebcc66a2b70eb2cc031ad70
Author: Patrice Dumas <pertusus@free.fr>
AuthorDate: Wed Feb 22 23:04:55 2023 +0100

    * tp/Texinfo/ParserNonXS.pm (_process_remaining_on_line),
    tp/Texinfo/XS/parsetexi/parser.c (process_remaining_on_line): explain
    why the next input is directly drawn after macro handling.
---
 ChangeLog                        | 6 ++++++
 tp/Texinfo/ParserNonXS.pm        | 7 ++++---
 tp/Texinfo/XS/parsetexi/parser.c | 6 ++++++
 3 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c6cd2074c8..84f04697de 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2023-02-22  Patrice Dumas  <pertusus@free.fr>
+
+       * tp/Texinfo/ParserNonXS.pm (_process_remaining_on_line),
+       tp/Texinfo/XS/parsetexi/parser.c (process_remaining_on_line): explain
+       why the next input is directly drawn after macro handling.
+
 2023-02-22  Gavin Smith <gavinsmith0123@gmail.com>
 
        Split ASCII_GLYPH and ASCII_PUNCTUATION
diff --git a/tp/Texinfo/ParserNonXS.pm b/tp/Texinfo/ParserNonXS.pm
index c33237bd3d..f19d86e17e 100644
--- a/tp/Texinfo/ParserNonXS.pm
+++ b/tp/Texinfo/ParserNonXS.pm
@@ -5084,9 +5084,10 @@ sub _process_remaining_on_line($$$$)
       ($expansion_error, $line, $source_info)
         = _handle_macro($self, $current, $line, $source_info, $command);
       if (!$expansion_error) {
-        # FIXME this is the same as in the XS parser, and it gives somewhat 
better
-        # results in test cases, avoiding useless text.  But it is unclear why
-        # it is so and if it is not covering up some other bug.
+        # directly get the following input (macro expansion text) instead
+        # of going through the next call of process_remaining_on_line and
+        # the processing of empty text.  No difference in output, more
+        # efficient.
         ($line, $source_info) = _next_text($self, $current);
       }
       return ($current, $line, $source_info, $retval);
diff --git a/tp/Texinfo/XS/parsetexi/parser.c b/tp/Texinfo/XS/parsetexi/parser.c
index 211a4c2180..26b5500d35 100644
--- a/tp/Texinfo/XS/parsetexi/parser.c
+++ b/tp/Texinfo/XS/parsetexi/parser.c
@@ -1689,6 +1689,12 @@ process_remaining_on_line (ELEMENT **current_inout, char 
**line_inout)
       expansion_error = handle_macro (current, &line, cmd);
       if (!expansion_error)
         {
+          /* directly get the following input (macro expansion text) instead
+             of going through the next call of process_remaining_on_line and
+             the processing of empty text.  No difference in output, more
+             efficient.
+           */
+
           free (allocated_line);
           allocated_line = next_text (current);
           line = allocated_line;