public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: <Paul_Koning@Dell.com>
To: <eliz@gnu.org>
Cc: <palves@redhat.com>, <dje@google.com>,
	<gdb-patches@sourceware.org>,	<stan@codesourcery.com>
Subject: Re: gdb.texinfo is getting too big
Date: Wed, 16 Oct 2013 20:10:00 -0000	[thread overview]
Message-ID: <C75A84166056C94F84D238A44AF9F6AD0372DC69@AUSX10MPC103.AMER.DELL.COM> (raw)
In-Reply-To: <83txghnfpe.fsf@gnu.org>


On Oct 16, 2013, at 4:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> Date: Wed, 16 Oct 2013 20:52:41 +0100
>> From: Pedro Alves <palves@redhat.com>
>> CC: Doug Evans <dje@google.com>, gdb-patches@sourceware.org,
>>        stan@codesourcery.com
>> 
>> Maybe it'd be easier to think in terms of things that would make
>> sense to split out of the main file.  E.g., the RSP chapter is useful
>> for GDB and stub developers, but not for regular users -- split that
>> one out.  Python scripting API stuff is useful for advanced users
>> that want to extend GDB, but it's not really the same class of manual
>> as the other chapters, so split that one out as another file too.
>> MI is useful for frontend writers, not for regular users, so out it
>> goes too.  Whatever other identifiable logic units we find, split
>> them out.  Then I suspect we'll end up with the core manual for
>> regular users that describes GDB's main features/CLI/commands,
>> and it'll be lean enough to be manageable.
> 
> You are talking about splitting the manual, whereas Doug was talking
> about splitting the sources while keeping a single manual as output.
> 
> I'm not sure I see a good reason to split the manual.  For starters,
> the size of that doesn't hurt as much as the size of the source file
> when you need to edit it.

Agreed.  There are plenty of examples of large manuals (GCC, GCCint, Emacs).  Divide them into as many source files as is convenient, that doesn't bother any user.  But having the manual (what users read) split into multiple parts is not a good change.

If we ever hit 5000 pages I might change my tune, but no GDB documentation is even close to that big.

	paul

  reply	other threads:[~2013-10-16 20:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-14 20:06 Doug Evans
2013-10-14 20:10 ` Eli Zaretskii
2013-10-14 20:26   ` Doug Evans
2013-10-15  2:44     ` Eli Zaretskii
2013-10-16 18:55       ` Doug Evans
2013-10-16 19:01         ` Eli Zaretskii
2013-10-16 19:52           ` Pedro Alves
2013-10-16 20:06             ` Eli Zaretskii
2013-10-16 20:10               ` Paul_Koning [this message]
2013-10-16 21:41                 ` Pedro Alves
2013-11-01 19:37                   ` Doug Evans
2013-11-01 19:57                     ` Eli Zaretskii
2013-10-16 21:29               ` Pedro Alves
2013-10-16 20:07       ` Stan Shebs

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=C75A84166056C94F84D238A44AF9F6AD0372DC69@AUSX10MPC103.AMER.DELL.COM \
    --to=paul_koning@dell.com \
    --cc=dje@google.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=stan@codesourcery.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).