From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: gdb-patches@sourceware.org
Subject: [doc patch] Move @menu to end of @node (Auto-loading)
Date: Tue, 27 Mar 2012 20:33:00 -0000 [thread overview]
Message-ID: <20120327203321.GA28113@host2.jankratochvil.net> (raw)
Hi Eli,
info '(texinfo)Menu Location'
# A menu must be located at the end of a node, without any regular text
# or additional commands between the `@end menu' and the beginning of the
# next node. (As a consequence, there may be at most one menu in a node.)
#
# This is actually a useful restriction, since a reader who uses the
# menu could easily miss any such text. Technically, it is necessary
# because in Info format, there is no marker for the end of a menu, so
# Info-reading programs would have no way to know when the menu ends and
# normal text resumes.
This is violated at multiple places in gdb.texinfo. But I see no problem from
that, info command displays it properly, also tested PDF (no menus) and HTML
(working menus).
So maybe I can just drop this patch, the menu looks better in the first part.
Thanks,
Jan
gdb/doc/
2012-03-27 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.texinfo (Auto-loading): Move @menu to the end of @node.
Create two new links fir 'objfile-gdb.py file'
and 'dotdebug_gdb_scripts section'.
--- ./gdb/doc/gdb.texinfo 27 Mar 2012 20:15:20 -0000 1.937
+++ ./gdb/doc/gdb.texinfo 27 Mar 2012 20:28:30 -0000
@@ -24714,13 +24714,9 @@ writable.
When a new object file is read (for example, due to the @code{file}
command, or because the inferior has loaded a shared library),
@value{GDBN} will look for Python support scripts in several ways:
-@file{@var{objfile}-gdb.py} and @code{.debug_gdb_scripts} section.
-
-@menu
-* objfile-gdb.py file:: The @file{@var{objfile}-gdb.py} file
-* dotdebug_gdb_scripts section:: The @code{.debug_gdb_scripts} section
-* Which flavor to choose?::
-@end menu
+@file{@var{objfile}-gdb.py} (@pxref{objfile-gdb.py file})
+and @code{.debug_gdb_scripts} section
+(@pxref{dotdebug_gdb_scripts section}).
The auto-loading feature is useful for supplying application-specific
debugging commands and scripts.
@@ -24767,6 +24763,12 @@ When reading an auto-loaded file, @value
function (@pxref{Objfiles In Python}). This can be useful for
registering objfile-specific pretty-printers.
+@menu
+* objfile-gdb.py file:: The @file{@var{objfile}-gdb.py} file
+* dotdebug_gdb_scripts section:: The @code{.debug_gdb_scripts} section
+* Which flavor to choose?::
+@end menu
+
@node objfile-gdb.py file
@subsubsection The @file{@var{objfile}-gdb.py} file
@cindex @file{@var{objfile}-gdb.py}
next reply other threads:[~2012-03-27 20:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-27 20:33 Jan Kratochvil [this message]
2012-03-27 20:40 ` Eli Zaretskii
2012-03-27 20:45 ` [commit] " Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120327203321.GA28113@host2.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox