bug-texinfo
[Top][All Lists]
Advanced

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

Re: Multiline @cindex entries misrender in groff Texinfo manual


From: G. Branden Robinson
Subject: Re: Multiline @cindex entries misrender in groff Texinfo manual
Date: Thu, 16 May 2024 14:21:21 -0500

Hi Dave,

At 2024-05-16T12:55:51-0500, Dave Kemper wrote:
> In a few places, the groff Texinfo manual uses a line-ending @ to
> continue a @cindex entry.  An example is:
> 
>   @DefreqList {tm, message}
>   @DefreqItemx {tm1, [@code{"}]message}
>   @DefreqListEndx {tmc, [@code{"}]message}
>   @cindex print to the standard error stream (@code{tm}, @code{tm1},@
>   @code{tmc})
>   @cindex standard error stream, write to (@code{tm}, @code{tm1},@
>   @code{tmc})
>   @cindex stream, standard error, write to (@code{tm}, @code{tm1},@
>   @code{tmc})
>   Send @var{message}, which consumes the remainder of the input line and
> 
> My version of makeinfo (texi2any (GNU texinfo) 6.7) doesn't render
> this as desired:
> 
>   -- Request: .tm message
>   -- Request: .tm1 ['"']message
>   -- Request: .tmc ['"']message
>       'tmc') 'tmc') 'tmc') Send MESSAGE, which consumes the remainder of
>       the input line and ...
> 
> That is, the continued @code{} tags are being put into the output
> rather than considered part of the index entry.

Right.  I see the problem in some output formats but not others.

DVI     no
HTML    yes
INFO    yes
PDF     no
TXT     yes

I suspect it's not a coincidence that DVI and PDF are the formats for
which texinfo uses TeX to generate the output.  Like *roff's "nroff" and
"troff" modes, texinfo has "tex" and "nottex" modes.  _Possibly_ some
@ifnottex logic internal to Texinfo (or "makeinfo") is messing up here.

> I don't know enough about the Texinfo language to know whether this is
> a bug in our manual or in makeinfo.

I don't know either.  IMO input line continuation should work the same
everywhere but one could charge that my view merely reflects my
knuckle-dragging bias in favor of *roff.  And I've had problems with
Texinfo's non-universal input line continuation convention before.

commit e8fe31fe6ba5b66b970285f4a6edb91663016813
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Tue Nov 14 23:27:49 2023 -0600

    doc/groff.texi: Fix style and markup nits.

    * Recast some concept index entries.
    * Break long input lines where possible.  Texinfo's `@newline` (they'd
      call it `@RET`) isn't as flexible as *roff's `\newline`.  (Texinfo's
      `@RET` always puts a space or break on the output, and isn't usable
      inside `@node` commands, for instance.  This means there's no way to
      avoid blowing past the file's configured text width except by luck or
      unless that value is huge.)

Maybe it's time to call an infoTeXpert to consult on these frustrations.
Updating mail headers accordingly.

> Does this render correctly in newer makeinfo versions?  makeinfo 6.7
> is fairly old,

Unfortunately that is the only version I have handy as well, so cannot
answer this.

> but the groff manual appears to require only 5.0 (as of commit
> 986d2a5b2, Apr 2020
> (http://git.savannah.gnu.org/cgit/groff.git/commit/?id=986d2a5b2)).

The idea here is that the groff Texinfo manual uses no Texinfo commands
that exist only in versions of texinfo later than 5.0.  There is no
guarantee that renderings from various Texinfo versions >= 5.0 will be
identical; that system gets to fix bugs over time just as ours does.

We do inherit a texinfo.tex file from gnulib, and which is pretty
recent.

\def\texinfoversion{2023-06-08.14}

...but I don't know what the priority ordering is for which texinfo.tex
is used during generation of the manual; the system one, or this one.
(This one, I would hope--else why provide it?)

Regards,
Branden

Attachment: signature.asc
Description: PGP signature


reply via email to

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