Re: warnings with cvs texinfo version
Hello,
Here is an additional patch that takes care of a new warning:
./gdb.texinfo:31: warning: @syncodeindex leads to a merging of fn in itself,
ignoring
It simply comments out the line
@syncodeindex fn fn
which is a bit weird.
On Wed, Jun 20, 2012 at 10:37:53PM +0200, Patrice Dumas wrote:
Hello,
The following warnings remain when using the cvs makeinfo version. It
is unclear to me how to solve these, but hipefully, you should be able
to fix them, or bear with warnings:
./gdb.texinfo:22939: warning: @table has text but no @item
These warnings are still there, but now to do what you wanted to do
with that construct, that is an indented environment without
anything else special, we added @indentedblock (and @smallindentedblock),
so I think that you could use that instead of an empty table.
./gdb.texinfo:35330: warning: @item missing argument
This warning is also still present. Here you can use, for example
@w{} but it will still be a rather dubious construct.
The other warnings have been removed.
--
Pat
Index: gdb/doc/gdb.texinfo
===
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.1039
diff -u -3 -p -r1.1039 gdb.texinfo
--- gdb/doc/gdb.texinfo 2 Jan 2013 15:00:34 - 1.1039
+++ gdb/doc/gdb.texinfo 5 Jan 2013 01:42:19 -
@@ -28,7 +28,7 @@
@c readline appendices use @vindex, @findex and @ftable,
@c annotate.texi and gdbmi use @findex.
@syncodeindex vr fn
-@syncodeindex fn fn
+@c @syncodeindex fn fn
@c !!set GDB manual's edition---not the same as GDB version!
@c This is updated by GNU Press.
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
On Sat, Jun 23, 2012 at 03:49:11PM +0300, Eli Zaretskii wrote:
That's true, but an asterisk '*' cannot be a valid label,
I can't see why.
Because of * Menu.
I still don't get it. It seems to me that
@menu
* *: mynode.
@end menu
is a perfectly valid menu entry, and same with @ref{mynode, , *}.
and there
should be a blank after *Note before the label.
That, I could agree with. I'll ask on the list.
This should be fixed now.
--
Pat
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
On Thu, Jun 21, 2012 at 05:52:55AM +0300, Eli Zaretskii wrote: ./gdb.texinfo:190: warning: @contents should only appear at beginning or end of document This warning is no longer there, it was not clearly wrong in formats other than TeX, and we don't want to have something specific for output formats. This issue will be revisited later, but in the mean time this one is no longer there... -- Pat ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Tue, 10 Jul 2012 22:39:58 +0200 From: Patrice Dumas pertu...@free.fr Cc: bug-gdb@gnu.org, k...@freefriends.org On Thu, Jun 21, 2012 at 05:52:55AM +0300, Eli Zaretskii wrote: ./gdb.texinfo:190: warning: @contents should only appear at beginning or end of document This warning is no longer there, it was not clearly wrong in formats other than TeX, and we don't want to have something specific for output formats. This issue will be revisited later, but in the mean time this one is no longer there... Thank you. ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
On Thu, Jun 21, 2012 at 10:54:15PM +0300, Eli Zaretskii wrote: I don't think so. If I am not wrong, a colon means that there is a label before the node name, but it still leads to a cross reference. That's true, but an asterisk '*' cannot be a valid label, I can't see why. and there should be a blank after *Note before the label. That, I could agree with. I'll ask on the list. -- Pat ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Sat, 23 Jun 2012 13:29:38 +0200 From: Patrice Dumas pertu...@free.fr Cc: bug-gdb@gnu.org, k...@freefriends.org On Thu, Jun 21, 2012 at 10:54:15PM +0300, Eli Zaretskii wrote: I don't think so. If I am not wrong, a colon means that there is a label before the node name, but it still leads to a cross reference. That's true, but an asterisk '*' cannot be a valid label, I can't see why. Because of * Menu. and there should be a blank after *Note before the label. That, I could agree with. I'll ask on the list. Thanks. ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
On Thu, Jun 21, 2012 at 10:51:16PM +0300, Eli Zaretskii wrote:
That demand would be satisfied by an optional warning. E.g., like
with GCC's -Wfoo switches.
As to whether this means that the manual is in bad shape, I would be
tempted to say that it is the case.
Here's the output that empty table produces:
...
Do you see anything bad shape here? I don't.
You missed my point. The manual is formatted fine, but since it uses an
undocummented Texinfo feature it is in a bad shape Texinfo-wise and the
formatting could change in the future, more or less drastically.
If you make such backwards incompatible changes in behavior, people
will complain, and rightly so.
Not rightly. Undocumented features should not be counted on.
How is an empty argument to @w any better than an empty @item? One
day someone might even decide that such empty arguments to @w don't
make sense, and will produce a warning for that, too.
Sure, unless the fact that an empty @item is wrong but an @item with an
empty @w{} is correct is documented in the manual, in which case it
becomes 'set in stone' that this is a correct construct.
The GDB manual has been using this form for a very long time now. So
long that it could definitely be considered an established de-facto
practice.
I don't think so. It instead shows that we need to state precisely if
it is correct or not.
Should that be documented?
Not sure what you suggest to document.
I suggest to document the correct constructs, such that expectations are
precise on what should lead to a warning or not.
A user-friendly tool lets users do whatever they want, so long as the
result is to users' liking. If I learned anything from the days back
when I was hacking makeinfo, it's that users will use the tools in
every imaginable way and some unimaginable ones. Restricting them or
annoying them with gratuitous messages, without a very good reason, is
just annoyance.
I interpret your point in the exact opposite direction. To me, the fact
that 'users will use the tools in every imaginable way and some
unimaginable ones' means that users should only have expectations on the
documented features, and that we may want to precise the right ways
at any time.
I am not sure, as the output may not be what the writer intended.
It is today.
For you in Info. But not necessarily for everybody in every format.
For instance, the docbook produced is invalid. It is not clear to me
that what comes before the first item should be indented or not.
Again, the empty @item line could either be ignored, or be considered as
an empty line depending on the formatter.
makeinfo never did such things, and IMO it never should.
If changes are relevant, for constructs that were previously
undocumented, makeinfo may change its output.
This has changed, now the text is:
Both contents commands should be written on a line by themselves, and
placed near the beginning of the file, after the @code{@@end
titlepage} (@pxref{titlepage,,@code{@@titlepage}}), before any
sectioning command. The contents commands automatically generate a
chapter-like heading at the top of the first table of contents page,
so don't include any sectioning command such as @code{@@unnumbered}
before them.
Maybe this could be clearer?
This is clear enough, but it's still doesn't contradict having
@contents after @top, because @top is not a sectioning command.
For me, it is. Maybe that could be clearer.
Again, limitations should have a good reason. What harm will having
@contents after @top do? If there's no harm, then please don't annoy
users by warnings that don't have a solid reason.
In TeX it doesn't work. If you look at the manual, the @top is in an
@ifnottex block, but the idea is that the rule about @contents should
not depend on the output format.
There is a balance between having more warnings to warn users that have
made mistakes and having less warnings to let the user have more
freedom, and where the cursor is is mostly arbitrary: you'll always
help some users and piss off others. Nowadays, there are more and more
warnings added. Personnally, I don't care much, Karl is the one
deciding on that in general.
Well, I surely hope Karl will reconsider. Because I think this policy
will bring nothing but complaints and aggravation.
I think that it depends whether there is a way to get things right or
not. For @contents, it is rather easy, as it may be moved before
sections in any format -- although the output in html and plaintext will
be different.
For the empty @item issue, using @w{} or something like that may be a
possible solution.
For the indentation provided by an empty @table, I have no idea for now.
--
Pat
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Sat, 23 Jun 2012 15:07:38 +0200
From: Patrice Dumas pertu...@free.fr
Cc: bug-gdb@gnu.org, k...@freefriends.org
You missed my point. The manual is formatted fine, but since it uses an
undocummented Texinfo feature it is in a bad shape Texinfo-wise and the
formatting could change in the future, more or less drastically.
If you make such backwards incompatible changes in behavior, people
will complain, and rightly so.
Not rightly. Undocumented features should not be counted on.
But they are, all the time. Breaking that causes users to complain,
and insisting on breaking them makes maintainers look unfriendly.
How is an empty argument to @w any better than an empty @item? One
day someone might even decide that such empty arguments to @w don't
make sense, and will produce a warning for that, too.
Sure, unless the fact that an empty @item is wrong but an @item with an
empty @w{} is correct is documented in the manual, in which case it
becomes 'set in stone' that this is a correct construct.
First, we should agree that one is right while the other is wrong,
and for that we need a good reason to reject the 'wrong one.
And second, documenting things rarely makes them set in stone,
because users have a habit of rejecting unreasonable (from their POV)
restrictions, even if they are documented.
A user-friendly tool lets users do whatever they want, so long as the
result is to users' liking. If I learned anything from the days back
when I was hacking makeinfo, it's that users will use the tools in
every imaginable way and some unimaginable ones. Restricting them or
annoying them with gratuitous messages, without a very good reason, is
just annoyance.
I interpret your point in the exact opposite direction. To me, the fact
that 'users will use the tools in every imaginable way and some
unimaginable ones' means that users should only have expectations on the
documented features, and that we may want to precise the right ways
at any time.
This doesn't work in practice, and I hope Texinfo will not go that
way.
If you look at the manual, the @top is in an @ifnottex block, but
the idea is that the rule about @contents should not depend on the
output format.
If there's no good reason for a rule, it simply should not exist.
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
On Thu, Jun 21, 2012 at 05:52:55AM +0300, Eli Zaretskii wrote: ./gdb.texinfo:22939: warning: @table has text but no @item Why is this warning needed? This one is clear to me. A @table without @item does not make sense. A @table specifies a series of headings and associated texts, so a @table without @item has no reason to be. I don't think this warning should be ignored. Maybe use @group? Or @quotation? What are you searching for with those empty tables? ./gdb.texinfo:35330: warning: @item missing argument And this one? @table is for a succession of headings and text. An empty item means no heading and thus is not suitable. I agree that it may make sense as a separator, to control the presentation, but the general idea is that Texinfo should not be used as a presentational markup, but instead as a descriptive markup, hence this warning. You can always ignore that warning, though. ./gdb.texinfo:190: warning: @contents should only appear at beginning or end of document That @contents _is_ at the beginning. What's the issue here? It is not at the very beginning, instead, it appears at the end of the top node and element. At the beginning would mean before @node Top You can ignore this warning, though. -- Pat ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
On Thu, Jun 21, 2012 at 05:56:49AM +0300, Eli Zaretskii wrote:
Date: Wed, 20 Jun 2012 22:37:53 +0200
From: Patrice Dumas pertu...@free.fr
Cc: Karl Berry k...@freefriends.org
./gdb.texinfo:11503: warning: @strong{Note...} produces a spurious
cross-reference in Info
No, it doesn't, not with a colon immediately following the Note.
My testing shows that it indeed does, at least with info (GNU texinfo)
4.13.
*Note*: a trace experiment and data collection may stop
-Info: (gdb.info)Starting and Stopping Trace Experiments, 123 lines --10%--
Cannot find node `a trace experiment and data collection may stop automatically
--
Pat
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Thu, 21 Jun 2012 15:50:29 +0200 From: Patrice Dumas pertu...@free.fr Cc: bug-gdb@gnu.org, k...@freefriends.org On Thu, Jun 21, 2012 at 05:52:55AM +0300, Eli Zaretskii wrote: ./gdb.texinfo:22939: warning: @table has text but no @item Why is this warning needed? This one is clear to me. A @table without @item does not make sense. A @table specifies a series of headings and associated texts, so a @table without @item has no reason to be. I don't think this warning should be ignored. Maybe use @group? Or @quotation? IMO, this is wrong in principle. It is not makeinfo's business to force style on the author of the manual. Warnings should only be emitted when the produced manual is in bad shape. This isn't such a case, so the warning is IMO gratuitous. If you want a pedantic mode (which could be a useful feature), please make it optional. What are you searching for with those empty tables? Indentation and consistent format of describing GDB features. ./gdb.texinfo:35330: warning: @item missing argument And this one? @table is for a succession of headings and text. An empty item means no heading and thus is not suitable. It doesn't come out empty in the output. Did you look at that? It produces this: `' which stands for an empty response. If you know of any other way of getting the same in a @samp typeface, please tell. I agree that it may make sense as a separator, to control the presentation, but the general idea is that Texinfo should not be used as a presentational markup, but instead as a descriptive markup, hence this warning. Again, this is wrong philosophy. This warning should at least be turned off by default. You can always ignore that warning, though. Extra noise runs the risk of obscuring real problems. ./gdb.texinfo:190: warning: @contents should only appear at beginning or end of document That @contents _is_ at the beginning. What's the issue here? It is not at the very beginning, instead, it appears at the end of the top node and element. At the beginning would mean before @node Top But the Texinfo manual documents no such restriction. It says only this: Both contents commands should be written on a line by themselves, and are best placed near the beginning of the file, after the `@end titlepage' (*note titlepage::). This is clearly an advisory, not a requirement. So I don't think a warning is called for. You can ignore this warning, though. I don't want to ignore warnings. Please don't introduce warnings that should be ignored. ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Thu, 21 Jun 2012 15:58:57 +0200
From: Patrice Dumas pertu...@free.fr
Cc: bug-gdb@gnu.org, k...@freefriends.org
On Thu, Jun 21, 2012 at 05:56:49AM +0300, Eli Zaretskii wrote:
Date: Wed, 20 Jun 2012 22:37:53 +0200
From: Patrice Dumas pertu...@free.fr
Cc: Karl Berry k...@freefriends.org
./gdb.texinfo:11503: warning: @strong{Note...} produces a spurious
cross-reference in Info
No, it doesn't, not with a colon immediately following the Note.
My testing shows that it indeed does, at least with info (GNU texinfo)
4.13.
*Note*: a trace experiment and data collection may stop
-Info: (gdb.info)Starting and Stopping Trace Experiments, 123 lines
--10%--
Cannot find node `a trace experiment and data collection may stop
automatically
Then perhaps the stand-alone Info reader should be fixed instead.
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
On Thu, Jun 21, 2012 at 07:15:47PM +0300, Eli Zaretskii wrote:
On Thu, Jun 21, 2012 at 05:52:55AM +0300, Eli Zaretskii wrote:
./gdb.texinfo:22939: warning: @table has text but no @item
Why is this warning needed?
This one is clear to me. A @table without @item does not make sense. A
@table specifies a series of headings and associated texts, so a @table
without @item has no reason to be. I don't think this warning should be
ignored. Maybe use @group? Or @quotation?
IMO, this is wrong in principle. It is not makeinfo's business to
force style on the author of the manual. Warnings should only be
emitted when the produced manual is in bad shape. This isn't such a
case, so the warning is IMO gratuitous.
This warning was primarily done to help writers avoid mistakes, after a
user demand (if I recall well). As to whether this means that the
manual is in bad shape, I would be tempted to say that it is the case.
The presentation of the text appearing before the first @item could
be formatted differently from the text appearing after the first @item,
so you cannot rely on having the presentation you want in the future.
It could even be discarded, be considered as a 'meta-data' (the table
title?). This is left unspecified for now in the manual such that we
can give any meaning to this text in the future. Such text should not
be used in the mean time, in my opinion.
That being said, I agree with you that there is no easy way to have a
consistent presentation as @quotation that would be more logical, at
least in TeX leads to different left margin. Any idea, Karl?
Indentation and consistent format of describing GDB features.
Ok.
It doesn't come out empty in the output. Did you look at that? It
produces this:
`'
Indeed, I missed it.
which stands for an empty response. If you know of any other way of
getting the same in a @samp typeface, please tell.
There is, for example:
@item @w{}
However if the table is formatted with @asis, there is no output. In
that case, using, for instance, @w{ }, leads to a line passed. Having
this difference may not be optimal, though.
Should that be documented?
I agree that it may make sense as a separator, to control the
presentation, but the general idea is that Texinfo should not be
used as a presentational markup, but instead as a descriptive
markup, hence this warning.
Again, this is wrong philosophy.
This is not a wrong philosophy, in my opinion this is the philosophy
behind Texinfo. I found that in the history of Texinfo (by chance):
A bit of history: in the 1970's at CMU, Brian Reid developed a program
and format named Scribe to mark up documents for printing. It used the
`@' character to introduce commands, as Texinfo does. Much more
consequentially, it strove to describe document contents rather than
formatting, an idea wholeheartedly adopted by Texinfo.
This warning should at least be turned off by default.
I am not sure, as the output may not be what the writer intended.
Again, the empty @item line could either be ignored, or be considered as
an empty line depending on the formatter. The fact that empty @item
lines should not be used is not said in the manual, though.
You can always ignore that warning, though.
Extra noise runs the risk of obscuring real problems.
Agreed.
./gdb.texinfo:190: warning: @contents should only appear at beginning
or end of document
That @contents _is_ at the beginning. What's the issue here?
It is not at the very beginning, instead, it appears at the end of the
top node and element. At the beginning would mean before
@node Top
But the Texinfo manual documents no such restriction. It says only
this:
Both contents commands should be written on a line by themselves, and
are best placed near the beginning of the file, after the `@end
titlepage' (*note titlepage::).
This is clearly an advisory, not a requirement. So I don't think a
warning is called for.
This has changed, now the text is:
Both contents commands should be written on a line by themselves, and
placed near the beginning of the file, after the @code{@@end
titlepage} (@pxref{titlepage,,@code{@@titlepage}}), before any
sectioning command. The contents commands automatically generate a
chapter-like heading at the top of the first table of contents page,
so don't include any sectioning command such as @code{@@unnumbered}
before them.
Maybe this could be clearer?
You can ignore this warning, though.
I don't want to ignore warnings. Please don't introduce warnings that
should be ignored.
There is a balance between having more warnings to warn users that have
made mistakes and having less warnings to let the user have more
freedom, and where the cursor is is mostly arbitrary: you'll always
help some users and piss off others. Nowadays, there are more and more
warnings added. Personnally, I don't care much, Karl
Re: warnings with cvs texinfo version
On Thu, Jun 21, 2012 at 07:17:40PM +0300, Eli Zaretskii wrote:
./gdb.texinfo:11503: warning: @strong{Note...} produces a spurious
cross-reference in Info
No, it doesn't, not with a colon immediately following the Note.
My testing shows that it indeed does, at least with info (GNU texinfo)
4.13.
*Note*: a trace experiment and data collection may stop
-Info: (gdb.info)Starting and Stopping Trace Experiments, 123 lines
--10%--
Cannot find node `a trace experiment and data collection may stop
automatically
Then perhaps the stand-alone Info reader should be fixed instead.
I don't think so. If I am not wrong, a colon means that there is a label
before the node name, but it still leads to a cross reference.
--
Pat
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Thu, 21 Jun 2012 19:18:19 +0200
From: Patrice Dumas pertu...@free.fr
Cc: bug-gdb@gnu.org, k...@freefriends.org
On Thu, Jun 21, 2012 at 07:15:47PM +0300, Eli Zaretskii wrote:
On Thu, Jun 21, 2012 at 05:52:55AM +0300, Eli Zaretskii wrote:
./gdb.texinfo:22939: warning: @table has text but no @item
Why is this warning needed?
This one is clear to me. A @table without @item does not make sense. A
@table specifies a series of headings and associated texts, so a @table
without @item has no reason to be. I don't think this warning should be
ignored. Maybe use @group? Or @quotation?
IMO, this is wrong in principle. It is not makeinfo's business to
force style on the author of the manual. Warnings should only be
emitted when the produced manual is in bad shape. This isn't such a
case, so the warning is IMO gratuitous.
This warning was primarily done to help writers avoid mistakes, after a
user demand (if I recall well).
That demand would be satisfied by an optional warning. E.g., like
with GCC's -Wfoo switches.
As to whether this means that the manual is in bad shape, I would be
tempted to say that it is the case.
Here's the output that empty table produces:
The following attributes are provided:
-- Variable: Value.address
If this object is addressable, this read-only attribute holds
a `gdb.Value' object representing the address. Otherwise,
this attribute holds `None'.
-- Variable: Value.is_optimized_out
This read-only boolean attribute is true if the compiler
optimized out this value, thus it is not available for
fetching from the inferior.
-- Variable: Value.type
The type of this `gdb.Value'. The value of this attribute is
a `gdb.Type' object (*note Types In Python::).
Do you see anything bad shape here? I don't.
The presentation of the text appearing before the first @item could
be formatted differently from the text appearing after the first @item,
so you cannot rely on having the presentation you want in the future.
It could even be discarded, be considered as a 'meta-data' (the table
title?). This is left unspecified for now in the manual such that we
can give any meaning to this text in the future.
If you make such backwards incompatible changes in behavior, people
will complain, and rightly so.
It doesn't come out empty in the output. Did you look at that? It
produces this:
`'
Indeed, I missed it.
which stands for an empty response. If you know of any other way of
getting the same in a @samp typeface, please tell.
There is, for example:
@item @w{}
How is an empty argument to @w any better than an empty @item? One
day someone might even decide that such empty arguments to @w don't
make sense, and will produce a warning for that, too.
The GDB manual has been using this form for a very long time now. So
long that it could definitely be considered an established de-facto
practice.
However if the table is formatted with @asis, there is no output.
That's true, but this is not an @asis table. If you want to limit
this warning to @asis, I'd be fine with that.
Should that be documented?
Not sure what you suggest to document.
I agree that it may make sense as a separator, to control the
presentation, but the general idea is that Texinfo should not be
used as a presentational markup, but instead as a descriptive
markup, hence this warning.
Again, this is wrong philosophy.
This is not a wrong philosophy, in my opinion this is the philosophy
behind Texinfo.
A user-friendly tool lets users do whatever they want, so long as the
result is to users' liking. If I learned anything from the days back
when I was hacking makeinfo, it's that users will use the tools in
every imaginable way and some unimaginable ones. Restricting them or
annoying them with gratuitous messages, without a very good reason, is
just annoyance.
This warning should at least be turned off by default.
I am not sure, as the output may not be what the writer intended.
It is today.
Again, the empty @item line could either be ignored, or be considered as
an empty line depending on the formatter.
makeinfo never did such things, and IMO it never should.
./gdb.texinfo:190: warning: @contents should only appear at beginning
or end of document
That @contents _is_ at the beginning. What's the issue here?
It is not at the very beginning, instead, it appears at the end of the
top node and element. At the beginning would mean before
@node Top
But the Texinfo manual documents no such restriction. It says only
this:
Both contents commands should be written on a line by themselves, and
are best placed near the beginning of the file, after the `@end
titlepage' (*note titlepage::).
This is clearly an advisory, not a requirement.
Re: warnings with cvs texinfo version
Date: Thu, 21 Jun 2012 19:24:51 +0200
From: Patrice Dumas pertu...@free.fr
Cc: bug-gdb@gnu.org, k...@freefriends.org
On Thu, Jun 21, 2012 at 07:17:40PM +0300, Eli Zaretskii wrote:
./gdb.texinfo:11503: warning: @strong{Note...} produces a spurious
cross-reference in Info
No, it doesn't, not with a colon immediately following the Note.
My testing shows that it indeed does, at least with info (GNU texinfo)
4.13.
*Note*: a trace experiment and data collection may stop
-Info: (gdb.info)Starting and Stopping Trace Experiments, 123 lines
--10%--
Cannot find node `a trace experiment and data collection may stop
automatically
Then perhaps the stand-alone Info reader should be fixed instead.
I don't think so. If I am not wrong, a colon means that there is a label
before the node name, but it still leads to a cross reference.
That's true, but an asterisk '*' cannot be a valid label, and there
should be a blank after *Note before the label.
FWIW, the Emacs Info reader doesn't have any problems figuring out
that this isn't a cross-reference. So perhaps the stand-alone reader
should follow suit.
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
warnings with cvs texinfo version
Hello,
The following warnings remain when using the cvs makeinfo version. It
is unclear to me how to solve these, but hipefully, you should be able
to fix them, or bear with warnings:
./gdb.texinfo:22939: warning: @table has text but no @item
./gdb.texinfo:22991: warning: @table has text but no @item
./gdb.texinfo:23247: warning: @table has text but no @item
./gdb.texinfo:23269: warning: @table has text but no @item
./gdb.texinfo:23860: warning: @table has text but no @item
./gdb.texinfo:23878: warning: @table has text but no @item
./gdb.texinfo:23939: warning: @table has text but no @item
./gdb.texinfo:23983: warning: @table has text but no @item
./gdb.texinfo:23998: warning: @table has text but no @item
./gdb.texinfo:24023: warning: @table has text but no @item
./gdb.texinfo:24036: warning: @table has text but no @item
./gdb.texinfo:24053: warning: @table has text but no @item
./gdb.texinfo:24081: warning: @table has text but no @item
./gdb.texinfo:24108: warning: @table has text but no @item
./gdb.texinfo:24768: warning: @table has text but no @item
./gdb.texinfo:24937: warning: @table has text but no @item
./gdb.texinfo:24950: warning: @table has text but no @item
./gdb.texinfo:25046: warning: @table has text but no @item
./gdb.texinfo:25110: warning: @table has text but no @item
./gdb.texinfo:25256: warning: @table has text but no @item
./gdb.texinfo:25275: warning: @table has text but no @item
./gdb.texinfo:25288: warning: @table has text but no @item
./gdb.texinfo:25301: warning: @table has text but no @item
./gdb.texinfo:35330: warning: @item missing argument
./gdb.texinfo:35500: warning: @item missing argument
./gdb.texinfo:35684: warning: @item missing argument
./gdb.texinfo:35708: warning: @item missing argument
./gdb.texinfo:35725: warning: @item missing argument
./gdb.texinfo:35742: warning: @item missing argument
./gdb.texinfo:35759: warning: @item missing argument
./gdb.texinfo:36021: warning: @item missing argument
./gdb.texinfo:36092: warning: @item missing argument
./gdb.texinfo:36113: warning: @item missing argument
./gdb.texinfo:36196: warning: @item missing argument
./gdb.texinfo:36228: warning: @item missing argument
./gdb.texinfo:36270: warning: @item missing argument
./gdb.texinfo:36298: warning: @item missing argument
./gdb.texinfo:36323: warning: @item missing argument
./gdb.texinfo:36340: warning: @item missing argument
./gdb.texinfo:36370: warning: @item missing argument
./gdb.texinfo:37019: warning: @item missing argument
./gdb.texinfo:37074: warning: @item missing argument
./gdb.texinfo:37234: warning: @item missing argument
./gdb.texinfo:37300: warning: @item missing argument
./gdb.texinfo:37410: warning: @item missing argument
./gdb.texinfo:37608: warning: @item missing argument
./gdb.texinfo:37741: warning: @item missing argument
./gdb.texinfo:190: warning: @contents should only appear at beginning or end of
document
./gdb.texinfo:11503: warning: @strong{Note...} produces a spurious
cross-reference in Info; reword to avoid that
./stabs.texinfo:81: warning: @contents should only appear at beginning or end
of document
./annotate.texinfo:89: warning: @contents should only appear at beginning or
end of document
--
Pat
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Wed, 20 Jun 2012 22:37:53 +0200 From: Patrice Dumas pertu...@free.fr Cc: Karl Berry k...@freefriends.org The following warnings remain when using the cvs makeinfo version. It is unclear to me how to solve these, but hipefully, you should be able to fix them, or bear with warnings: Thanks, but... ./gdb.texinfo:22939: warning: @table has text but no @item Why is this warning needed? ./gdb.texinfo:35330: warning: @item missing argument And this one? ./gdb.texinfo:190: warning: @contents should only appear at beginning or end of document That @contents _is_ at the beginning. What's the issue here? ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
