Multiline @cindex entries misrender in groff Texinfo manual
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.
I don't know enough about the Texinfo language to know whether this is
a bug in our manual or in makeinfo. Does this render correctly in
newer makeinfo versions? makeinfo 6.7 is fairly old, 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)).
Re: Greek in Groff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 After changing the doc.ref encoding from UTF-8 to ISO8859-7 the references fonts change but they are still unreadable. I also tested the following command: groff -k -ms -R -Tutf8 doc.ms | cat -s which also has the same results. Greek fonts renter as expected in the document body but not in references. Is there something wrong happening when refer (-R) encodes Greek characters? -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEJtUPjkpB4OvgyQ2ynbVYFoZvRQQFAmZGThQACgkQnbVYFoZv RQSDXxAAxr5cJPkk/p/hTn4GJTIWYUbtzJnuMh+t5DR1tOKI1JnT0ByAahr0ZLhn QXepcnJd0NoerSWcYKYwQR7A5f0dkZwqtN1bRMQblavPcK4I+g6LfyqZZQMsXRkt mbSefq28GrTeeDh6A7xceyWpfuzRCDMT4rF6klp60OeBNml6OYRxoamXxRW4qwaN WhlcLq2YxWQ7GFqmGiKNnhNePea3Tn8CcXepbRUXsQQ1V+sgcybZ+9gydCPsUpq9 IkxRl78SkSmb3Affjo/iQyv2jUVdlPbWGb7qnE2u/OtYjb03Medwb0G1hJO0f8pu mfY6YaRpkQyyhj7KZs0qy1jqvtINzWmygaH1tQ6Syvofu49K6SPRmSNr0vPBZbaM ioFtWTZ8TYERc7rCBVvL/UtHjXeJaNU57OeDsihGNHCNg3F+A+XEi3UWIMRhUTcs ZDs2HIagVluRjvA+lBWp0j+zw6K0Tw1t7h/0dXkReoDx9bxRtnb5pmsiMzWVvzP/ OnEPaPKQn8aG0URzmq3TpyDPtAF/CBzaTqUrT9xZxDmt67l2m4GI8uuuK5IO+V3D hPG4y2KlYzv+uFKZcZTQnv4ZlQodC7BjCISLbdhh0TN19yOF5NgwZKEBCdTtjp0l oBnMKncH23ecOLvDeDYg7Esq5c9CPssc211uGHN9kmXdZgcPdBU= =eof+ -END PGP SIGNATURE-
Re: Multiline @cindex entries misrender in groff Texinfo manual
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
HTMLyes
INFOyes
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
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
signature.asc
Description: PGP signature
Re: Multiline @cindex entries misrender in groff Texinfo manual
On Thu, May 16, 2024 at 02:21:21PM -0500, G. Branden Robinson wrote:
> 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:
> >
> > @cindex print to the standard error stream (@code{tm}, @code{tm1},@
> > @code{tmc})
> >
> > My version of makeinfo (texi2any (GNU texinfo) 6.7) doesn't render
> > this as desired:
> >
> > '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.
There is a specific context in which @ followed by a newline is removed
and the line is not considered to be ended, on the @def* command line.
It is said explicitely in that section that in other contexts, the @
followed by a newline is not a continuation character:
https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Def-Cmd-Continuation-Lines
In the manual it is said that @ followed by a new line leads to the
insertion of a single space in the output:
https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Inserting-Space
It is never said in the manual very explicitely whether a @ followed by a new
line ends an @-command line or not, but the line @-command is described as
being on a line:
https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Command-Syntax
So my interpretation is that @ followed by a space both produces a
single space and ends the @-command line (except on @def* where it
produces nothing and does not end the @-command line).
In your case, you should write
@cindex print to the standard error stream (@code{tm}, @code{tm1}, @code{tmc})
> 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.
Indeed, seems like @ followed by a new line does not ends the @-command
line in Texinfo TeX. I don't know if it should be considered as
undefined behaviour or if TeX (or makeinfo, though I'd say that makeinfo
is right...) should be changed. I'd lean towards undefined behaviour in
that case.
> > 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.
It is the same in the development version, and my wild guess is that it
is the same since at least 5.0, but I have not tested.
> ...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?)
Should be this one.
--
Pat
