From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9267 invoked by alias); 12 Feb 2007 17:35:58 -0000 Received: (qmail 9259 invoked by uid 22791); 12 Feb 2007 17:35:57 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 12 Feb 2007 17:35:51 +0000 Received: (qmail 24742 invoked from network); 12 Feb 2007 17:35:49 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Feb 2007 17:35:49 -0000 To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: Special characters in doc strings of GDB commands References: <20070210204729.GA29601@nevyn.them.org> From: Jim Blandy Date: Mon, 12 Feb 2007 17:58:00 -0000 In-Reply-To: <20070210204729.GA29601@nevyn.them.org> (Daniel Jacobowitz's message of "Sat, 10 Feb 2007 15:47:29 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00082.txt.bz2 Daniel Jacobowitz writes: > On Fri, Jan 19, 2007 at 01:36:56PM +0200, Eli Zaretskii wrote: >> I see in cli-decode.c:print_doc_line that it displays the first line >> only up to the first comma or period. However, I don't see this >> special treatment of these two characters documented anywhere, neither >> in gdb.texinfo (where it matters for doc strings given to user-defined >> commands), nor in gdbint.texinfo (where it is important for GDB >> developers who add new commands). >> >> Am I missing something? > > Not as far as I know. > >> Btw, should we have a mechanism to escape these special characters, at >> least the comma? Sometimes a sentence looks very awkward or even >> unclear unless you use a comma. > > Isn't this whole mechanism horribly i18n-unfriendly already? Perhaps > we should just change it... My understanding is that the first line should be a self-contained summary. If there is additional text on the first line, it should be moved onto the second line. Then, print_doc_line could stop at the line break.