Re: rethinking @def*

[pertusus]

On Tue, Jul 26, 2022 at 04:17:08PM +0000, Werner LEMBERG wrote:
> 
> > but the manual is not so clear on what is in typewriter and what is
> > not in @def* arguments.  Also for lisp manuals which rely on &word
> > being bold, it could require some additional markup, but this is not
> > really documented, except in "Inserting ‘&’ with @& and @ampchar{}".
> 
> Again: While a lot of behaviour is not properly documented, people
> *rely* on those formatting details.  Instead of changing the
> formatting for those old commands I rather suggest to document them
> properly – this can also be used as a soft hint to update to newer and
> more consistent commands.

It is not very clear to me what you mean by "document them properly".

> BTW, if TeX and HTML output differed for those commands in
> undocumented ways, this would be something else.  In such cases it
> would be OK with me to adjust `texinfo.tex`.

TeX and HTML output are very different, name in @strong in HTML, whole
argument in @emph, as well as type, nothing in typewriter in HTML.
Nothing is said in the manual on the HTML formatting of @def* actually.
And I think that it is better if it stays that way, and if there is
n cnvergence of the formatting, Texinfo should be about semantics, not
about frmatting.

> >> I thus strongly suggest that you implement *new* commands, say,
> >> `@define`, `@define*`, etc., that have better semantics.
> > 
> > I do not think that it is a good idea.  The semantics are not really
> > changing, in my opinion, because they were ill specified and
> > inconsistent before, adding different commands would seem wrong to
> > me.  Only the formatting is changing.
> 
> The last two sentences looks strange.  I have difficulties to
> understand them.  Please reformulate.

The "old" commands do not have much of semantics, and when they have,
these semantics are inconsistent in different places in the manual.
Therefore new commands would not have better semantics, they would
simply have semantics that are currently lacking.  Therefore it seems
wrong to me to have two sets of @def* commands, with the same syntax, one
without semantics, and one with semantics.  Only one set of commands
with clear semantics should be enough.

-- 
Pat