From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15624 invoked by alias); 16 Oct 2013 19:52:53 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 15612 invoked by uid 89); 16 Oct 2013 19:52:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Oct 2013 19:52:52 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9GJqiUX003810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Oct 2013 15:52:45 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r9GJqfCu029773; Wed, 16 Oct 2013 15:52:42 -0400 Message-ID: <525EEE89.9060907@redhat.com> Date: Wed, 16 Oct 2013 19:52:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eli Zaretskii CC: Doug Evans , gdb-patches@sourceware.org, stan@codesourcery.com Subject: Re: gdb.texinfo is getting too big References: <83ob6rpqa5.fsf@gnu.org> <83mwmbp80v.fsf@gnu.org> <83zjq9nipu.fsf@gnu.org> In-Reply-To: <83zjq9nipu.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-10/txt/msg00496.txt.bz2 On 10/16/2013 08:01 PM, Eli Zaretskii wrote: >> Date: Wed, 16 Oct 2013 11:55:00 -0700 >> From: Doug Evans >> Cc: gdb-patches , Stan Shebs >> >> The worry I have with any kind of grouping not based on the doc itself >> is that it introduces a potentially non-intuitive layer that someone >> has to learn in order to know which file contains the text one wants >> to edit. grep will find it of course, but if one is having to grep >> too much, would that be a problem? > > Emacs uses this scheme, and I didn't hear any complaints, FWIW. 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. -- Pedro Alves