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

[Michael Snyder <msnyder@vmware.com>]

Michael Snyder wrote:
> 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.

Got it.  I can split this up like this:


   internal_error (__FILE__, __LINE__,
                   _("gen_var_ref: LOC_CONST_BYTES "
                     "symbols are not supported"));

Submission to follow after final regression test.