[Top][All Lists]

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

Re: rethinking @def*

From: Patrice Dumas
Subject: Re: rethinking @def*
Date: Tue, 26 Jul 2022 16:08:52 +0200

On Tue, Jul 26, 2022 at 02:48:39PM +0100, Gavin Smith wrote:
> On Tue, Jul 26, 2022 at 03:24:34PM +0200, Patrice Dumas wrote:
> > > >    * for the other @-commands, the argument is considered to be
> > > >      metasyntactic variable (in code as per rule 1)).
> > > > 
> > > 
> > > @var should used to wrap function arguments or parameters.  This is a more
> > > straightforward definition than whatever "metasyntactic variables"
> > > are.  @var can be used for metasyntactic variables too, if they occur
> > > elsewhere outside the context of a @def* line.
> > > 
> > > I'm not sure what you mean by the "other @-commands"; is it just @var or
> > > are there other commands you had in mind?
> > 
> > Actually , what I meant was
> >     * for the other @def* @-commands, the argument is considered to be
> >       metasyntactic variable (in code as per rule 1)).
> > 
> > If I understand you correctly, but I may be misinterpreting, you would
> > propose something even simpler and somewhat less backward incompatible,
> > that there is no semantics other than being in code for all the @def*
> > 'argument', such that @var{} would need to be explicitly set.  So for
> > example
> > 
> >  @defspec foobar (var [from to [inc]]) body@dots{}
> > would need to be rewritten as
> >  @defspec foobar (@var{var} [@var{from} @var{too} [@var{inc}]]) @var{body} 
> > @dots{}
> That's what I'd thought, but on checking it I am not so sure.  At present
> the first line is output in a slanted font.  Changing it to be like @code
> by default would lead it to output in a fixed width font, which is not
> necessarily an improvement: we lose the slant (bad) but gain the fixed
> width (good).  What would be better is to have both the slant and fixed width
> by default (maybe that's what you were proposing in the first place).

Exactly, that's what I was proposing, at least for @def* @-commands that
are not @deftype*.  For @deftype*, no slant in the default case, need to
add @var explicitely.

As a side note, even if we have slant in the default case for non
@deftype* def commands, we could also start to recommend using
explicitly @var{} to mark metasyntactic variables on all the @def*
@-command lines, even if this has no effect on the formatting.

> We'd have to check that we could do this easily as the separator characters
> like ( [ ] ) on the definition line shouldn't themselves be slanted.  Current
> texinfo.tex doesn't slant those, so perhaps there isn't a problem here.

I think that it actually depends on how the separator characters are
used.  If they are true separators, an actual (, or an actual comma ,
that is part of the programming language syntax, they should not be
slanted.  If they are parentheses or [] that are used to specify that
an argument is optional, or how arguments are grouped, as a kind of
meta syntax, it seems to me that having them slanted could actually
be better, in particular if there are true separators mixed.  It
probably depend to some extent on some the 'taste' of the writers.


reply via email to

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