From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3512 invoked by alias); 5 Jan 2011 09:02:55 -0000 Received: (qmail 3491 invoked by uid 22791); 5 Jan 2011 09:02:53 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.156) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Jan 2011 09:02:48 +0000 Received: from md1.u-strasbg.fr (md1.u-strasbg.fr [IPv6:2001:660:2402::186]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id p0592iuO021290 ; Wed, 5 Jan 2011 10:02:44 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms1.u-strasbg.fr [130.79.204.10]) by md1.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id p0592h3I043771 ; Wed, 5 Jan 2011 10:02:44 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from E6510Muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id p0592heo024039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) ; Wed, 5 Jan 2011 10:02:43 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Michael Snyder'" Cc: References: <4D237089.1080309@vmware.com> <000c01cbac44$48830210$d9890630$@muller@ics-cnrs.unistra.fr> <4D237C6A.9050609@vmware.com> In-Reply-To: <4D237C6A.9050609@vmware.com> Subject: RE: [patch] Shorten lines of >= 80 columns. Date: Wed, 05 Jan 2011 09:02:00 -0000 Message-ID: <000001cbacb7$4fc38f40$ef4aadc0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2011-01/txt/msg00072.txt.bz2 > > case LOC_CONST_BYTES: > > - internal_error (__FILE__, __LINE__, > > - _("gen_var_ref: LOC_CONST_BYTES symbols are not > > supported")); > > + internal_error (__FILE__, __LINE__, _("\ > > +gen_var_ref: LOC_CONST_BYTES symbols are not supported")); > > > > I think this kind of changes confuses cvs > > for the 'cvs diff -u -p': > > it might regard the new line > > +gen_var_ref: LOC_CONST_BYTES symbols are not supported")); > > as a new starting function line and > > report a wrong function name... > > Of course not really for your example here, > > as the start of the line is > > the name of the function itself... > > But I remember having seen > > wrong function name reported with 'cvs -u -p' > > due to the use of '_("\' > > construct which force starting next line without > > spaces... > > > > Pierre Muller > > GDB pascal language maintainer > > > Hmmm... well, we already have tons of similar constructs in the tree. Yes, I know, and it should of course not retard your commit. I was just wondering if we could try to avoid those construct in the future, but I am not sure there is a simple solution... In general, I was wondering if we could use ,_( "gen_var_ref: LOC_CONST_BYTES symbols are not supported")); instead of ,_("\ gen_var_ref: LOC_CONST_BYTES symbols are not supported")); at least for case that are shorter than 80 - 5(2'"'+2')'+1';') chars? But this might be against GNU coding style. Pierre Muller GDB pascal language maintainer