[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Deprecate Texinfo commands

From: Patrice Dumas
Subject: Re: Deprecate Texinfo commands
Date: Thu, 12 Nov 2020 01:13:12 +0100

On Wed, Nov 11, 2020 at 07:05:17PM +0000, Gavin Smith wrote:
> > 
> > I think that the arguments should be separated by commas both for
> > consistency and also because we eventually want to allow for spaces in
> > arguments.  Also I think that it would be much better if the arguments
> > were semantically defined.  The first argument could be the language,
> > the second a hint about the size.
> Could arbitrarily many arguments be provided?  Are there any other
> Texinfo commands which are variadic (separating arguments with commas)?

There are @node and @float, and also @definfoenclose and @pagesizes
although @pagesizes and @definfoenclose only accept specific arguments.
Some @-commands do not use commas, but they are very specific (@alias,
@syn*index, @def*).

Regarding the number of arguments, I think that right now it should be
specified, in particular because trailing commas after the last possible
argument are considered to be part of the last argument.  That being
said, it would probably be easy to change the parser code to accept
infinite number of arguments.  I think that for block commands setting
$block_commands{$command} to -1 in Common.pm and changing in
ParserNonXS.pm l 4680 to handle $block_commands{$command} set to -1 

              $current->{'remaining_args'} = $block_commands{$command} -1
                if ($block_commands{$command} =~ /^\d+$/
                    and $block_commands{$command} -1 > 0);
to (untested)
              if ($block_commands{$command} =~ /^\d+$/
                  and $block_commands{$command} -1 > 0) {
                $current->{'remaining_args'} = $block_commands{$command} -1;
              } elsif ($block_commands{$command} == -1) {
                $current->{'remaining_args'} = -1;
would be enough, since a negative number is 'true'.

> Maybe there won't be any uses for this feature other than source
> language and size, so it won't matter.  I don't like making size part
> of the language, though: I thought of this as a hack to be used when
> you couldn't avoid it, rather than something to be encouraged.

I agree, I think that we should stick as much as possible to a semantic
language.  But unless I am missing something the idea here is to cover
@smallexample use case, so this means making size part of the language.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]