Mon 20 Oct 2014 05:11:33 AM UTC, comment #8:
It works now as expected, thanks!
|
Sun 19 Oct 2014 09:46:59 PM UTC, comment #7:
The original isse (words splitting in @def) should be fixed in svn, as you proposed: text and @-commands intermingled without spaces are treated as one word in the name/category/type part of the @def line.
For now I haven't carried that change to the arguments part of the line, because I was under the impression that @var{} and @code{} are special here, so that it is unclear that words at @var{} and @code{} is not the right thing to do. I am not sure that it is problematic, though, since in the arguments part of @def line, there are no spaces added, spaces put by the user are kept as is.
I close, please reopen if you think this is not fixed.
|
Wed 15 Oct 2014 05:12:18 AM UTC, comment #6:
Regarding #4: This is interesting, and you have a point here. Unfortunately, your argumentation is
(a) not backwards compatible,
(b) not reflecting what `texinfo.tex' is currently doing, and
(c) non-intuitive: For me, a `word' in this context is something delimited by spaces – this is what Joe User expects also, I guess.
Regarding #5: I strongly disagree to make Patrice's interpretation the default! I would much favour to fix the current behaviour of makeinfo.
|
Wed 15 Oct 2014 04:57:25 AM UTC, comment #5:
Karl wrote:
Regarding @*heading, sadly, I am pretty sure I have seen more than one document abuse those commands to randomly format text inside blocks. I believe the text in the manual really meant to say "not relating to the node/sectioning structure" rather than be interpreted as literally "anywhere", but we should probably support it if we can. I'll see if I can make it work (again?) in TeX.
|
Wed 15 Oct 2014 04:52:59 AM UTC, comment #4:
[To have the complete discussion on the bug tracker, I'm adding comments sent to the bug-texinfo mailing list.]
Patrice:
It is on purpose. An @-command delimitates a special value on the @def* line, in the same way as braces do (except when in the ARGUMENTS... part), so @t{A} is an argument, and then it gets its space. The manual says:
As a general rule, when any of the arguments in the heading line
except the last one are more than one word, you need to enclose them
in braces. This may also be necessary if the text contains commands,
for example, '{declaraci@'on}' if you are writing in Spanish.
Which means, in my opinion, that you should have put braces.
That being said, it is not specified in the manual that a braced command delimitates a value on a @def* line, so this could also be changed.
|
Tue 14 Oct 2014 04:05:57 AM UTC, comment #3:
Sigh. `Dark corners'...
Well, the current git version of groff.texinfo now converts fine to PDF with both texinfo 4.x and 5.x. The PDF can be generated with
texi2dvi -e --pdf groff.texinfo
and the info file with
makeinfo --enable-encoding groff.texinfo
What exactly do you mean with `not easy to deal with the source tree'?
|
Mon 13 Oct 2014 05:58:24 PM UTC, comment #2:
confirmed, will pursue, thanks for the report.
yes, you have mentioned groff.texinfo as a test case many times, and i have in fact run it as a test many times. but your manual is so complicated and uses so many dark corners of the language, it has never seemed feasible to automate such a test. it's not easy to deal with the source tree, either. sorry, but that's my reality.
best,
karl
|
Sun 12 Oct 2014 02:15:03 PM UTC, comment #1:
BTW, this is a regression compared to the 4.x series of texinfo.
|
Sun 12 Oct 2014 01:47:59 PM UTC, original submission:
The following code
@deffn X @t{A}B@t{C}
@end deffn
if processed with `makeinfo' creates the following code in the info file:
-- X: A BC
Note the invalid space after `A'. groff.texinfo uses this construction a lot, and there is a big difference between the correct
\B'anything'
and the incorrect
\B' anything'
I think I mentioned multiple times that the groff texinfo manual is a good test for makeinfo and friends ...
|