From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18099 invoked by alias); 27 Sep 2002 17:55:48 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18091 invoked from network); 27 Sep 2002 17:55:47 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 27 Sep 2002 17:55:47 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7D5163D39; Fri, 27 Sep 2002 13:55:47 -0400 (EDT) Message-ID: <3D949BA3.4050807@redhat.com> Date: Fri, 27 Sep 2002 10:55:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc/rfa:doco] Use @sc{gdb}? References: <3D66B84F.6010803@ges.redhat.com> <2593-Sat24Aug2002123336+0300-eliz@is.elta.co.il> <3D934695.1020306@redhat.com> <8011-Fri27Sep2002193913+0300-eliz@is.elta.co.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00669.txt.bz2 >> Date: Thu, 26 Sep 2002 13:40:37 -0400 >> From: Andrew Cagney >> > >> >> Date: Fri, 23 Aug 2002 18:33:51 -0400 >> >> From: Andrew Cagney >> >> >> >> I got annoyed at all the GDB's in the formatted manual being really >> >> large so tried changing them to @sc{gdb}. It fixed that problem but I'm >> >> not sure that I like the final result :-) (You'll need to build >> >> gdb.pdf, gdb ps or gdb.dvi). >> >> >> >> Is there a style guide thing on this one? Eli? > >> > >> > >> > There are no strict rules on this one, AFAIK. If the results of >> > @sc{gdb} look nice to people, let's do it; if not, let's not. >> > >> > Personally, I like the results of @sc in such cases. > >> >> So, decision time. Trunk and 5.3 branch? > > > Fine with me. As long as the manual can be produced in all the > supported formats without error messages, this change cannot possibly > screw up the upcoming release 5.3. Good point. I've committed it to just the trunk. Andrew