[Top][All Lists]

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

Re: rethinking @def*

From: pertusus
Subject: Re: rethinking @def*
Date: Wed, 27 Jul 2022 11:29:20 +0200


I looked at the libc manual and the @deftype* formatting indeed looks
wrong.  The function type is in upright @code, which looks good,
but types within the function call are in slanted roman, and
metasyntactic variables are in slanted typewriter.  It seems very
strange.  I am actually very surprised that nobody complained.  Also,
it is somewhat strange that after the change in 2003, similar change was
not followed up on the argument.

Upright parenthese and brackets tend to look better, though.  To me it
would be more logical to use typewriter upright parenthese and brackets,
but we could keep roman upright parenthese and brackets for backward

My current proposal would be
* @var is not in typewriter anymore, even if in code context (@code,
  @example, @def* line).  If people really want slanted typewriter,
  they should use @code{@slanted{}} or to be sure not to be affected
  by the current font style: @r{@code{@slanted{}}}

* @def* argument semantics is different for @deftype* and other @def*
  @deftype* argument is code.  Not slanted, but typewritter.  @var should
    be used which will lead to upper case in Info, unless something else is
    used, like @Var{} in the groff manual, which uses @r{@slanted{...}}
    (though it would be better in my opinion, to use @inline conditionnals
    to use @var except for Info).

  other @def* argument is code and metasyntactic variables in term of
    semantics, slanted, but not upper cased in Info.  Users can use
    @var explicitely, in that case, in Info the the argument will be upper

* in @def* arguments, parentheses/brackets are upright in the default case.
  For the font there are two possibilities (Gavin?)
  - typewritter. More logical. Not backward compatible (though it is not
    typewritter currently probably by chance, because of implementation
  - roman. Backward compatible but less logical.

  The parentheses font should only matter for manuals such as groff
  where parentheses/brackes as meta syntactic delimiter and as language
  delimiters are distinguished.


reply via email to

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