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

[Michael Snyder <msnyder@vmware.com>]

Pierre Muller wrote:
>>>      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.

No, I'm concerned about it.  If I can see a "nice" solution, I will
make changes.

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

The trouble with that is that emacs will not indent it that way.