makeinfo bug: macros with no arguments don't work as expected

View: New views
5 Messages — Rating Filter:   Alert me  

makeinfo bug: macros with no arguments don't work as expected

by Bruno Haible :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

I'm using makeinfo-4.13, and define a macro that should take no arguments
and should produce an empty expansion. The texinfo doc says:

    If a macro needs no parameters, you can define it either with an empty
  list (`@macro foo {}') or with no braces at all (`@macro foo').

When I define the macro as follows:

  @macro texnl{}
  @end macro

and my input text is:

  This is a more low-level API.  The word break property is a property defined
  in Unicode Standard Annex #29, section ``Word Boundaries'', see
  @url{http://www.unicode.org/reports/tr29/#Word_Boundaries}.@texnl  It is used
  for determining the word breaks in a string.

then makeinfo produces an info file with this paragraph:

     This is a more low-level API.  The word break property is a property
  defined in Unicode Standard Annex #29, section "Word Boundaries", see
  `http://www.unicode.org/reports/tr29/#Word_Boundaries'.  for
  determining the word breaks in a string.

You can see that the words "It is used" have been omitted. I.e. the macro
is acting like @c.

Whereas when I define the macro as follows:

  @macro texnl
  @end macro

then the output in info format is as expected:

     This is a more low-level API.  The word break property is a property
  defined in Unicode Standard Annex #29, section "Word Boundaries", see
  `http://www.unicode.org/reports/tr29/#Word_Boundaries'.  It is used for
  determining the word breaks in a string.


Bruno



Re: makeinfo bug: macros with no arguments don't work as expected

by Ben Pfaff :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Bruno Haible <bruno@...> writes:

> When I define the macro as follows:
>
>   @macro texnl{}
>   @end macro
>
> and my input text is:
>
>   This is a more low-level API.  The word break property is a property defined
>   in Unicode Standard Annex #29, section ``Word Boundaries'', see
>   @url{http://www.unicode.org/reports/tr29/#Word_Boundaries}.@texnl  It is used
>   for determining the word breaks in a string.

I think that bare @texnl is not allowed.  The "Invoking Macros"
section in the Texinfo manual says that you are supposed to use
@texnl{}:

        The braces are required in the invocation (but not the
        definition), even when the macro takes no arguments,
        consistent with all other Texinfo commands.
--
Ben Pfaff
http://benpfaff.org




Re: makeinfo bug: macros with no arguments don't work as expected

by Bruno Haible :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

An update on this one:

When I define the macro through
  @macro texnl{}
  @end macro
and invoke it through
  @texnl
then it eats up all text until the next newline, like @c.

When I define the macro through
  @macro texnl
  @end macro
and invoke it through
  @texnl
then it eats up all spaces immediately following the macro call.

Only @texnl{} appears to work right.

Can this be either fixed or a warning added to the documentation?

Bruno



Re: makeinfo bug: macros with no arguments don't work as expected

by Karl Berry :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

    Only @texnl{} appears to work right.

    Can this be either fixed or a warning added to the documentation?

As previously stated, it already is in the documentation.  What would be
more useful is to have a warning in the code.  Patrice?

Thanks,
k




Re: makeinfo bug: macros with no arguments don't work as expected

by Patrice Dumas :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, May 06, 2009 at 04:48:01PM -0500, Karl Berry wrote:
>     Only @texnl{} appears to work right.
>
>     Can this be either fixed or a warning added to the documentation?
>
> As previously stated, it already is in the documentation.  What would be
> more useful is to have a warning in the code.  Patrice?

Done.

--
Pat