bug-texinfo
[Top][All Lists]
Advanced

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

Re: rethinking @def*


From: Werner LEMBERG
Subject: Re: rethinking @def*
Date: Tue, 26 Jul 2022 16:17:08 +0000 (UTC)

>> ... I consider this a bad idea.  Whatever you are going to change,
>> it will be backward incompatible, causing a lot of grief.
> 
> It is only backward incompatible in term of formatting, not in term
> of Texinfo language or syntax

Yes, and I consider this as bad.  As I mentioned in my previous
e-mail, such a change would ruin any fine-tuning of the formatting – a
formatting that stayed unmodified for a very long time.

> We should still be as conservative as possible, but in that case, I
> think that the formatting is wrong, because the semantic is not well
> defined, such that changing the formatting is a way to fix it.

I disagree.  The right way IMHO is to go a soft route, not using a
sledgehammer.

> The most non backward compatible change I propose is that @deftype*
> not to be slanted anymore.

Yes, and all documents that expect the old behaviour have to suddenly
update.

>  Also there would be more typewriter fonts,

The same.

> 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.

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`.

>> For example, the adjustments to document troff commands (in the
>> groff info manual) are quite tricky, trying very hard to overcome
>> the various limitations and formatting issues of `@def` and
>> friends.
> 
> Would the change I propose require to modify those adjustments?
> Would the new formatting be incorrect?

Probably yes (I'm no longer in groff business), however, ...

> The change I propose are not that much backward incompatible.

... there is no such thing as being a little bit pregnant – and the
same holds for backward compatibility.

>> 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.


    Werner

reply via email to

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