RE: [patch] Shorten lines of >= 80 columns.

["Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>]

> >      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