On Tue, Apr 10, 2012 at 5:23 PM, Mike Stump <mikest...@comcast.net> wrote:
> On Apr 10, 2012, at 11:52 AM, Gabriel Dos Reis wrote:
>> On Tue, Apr 10, 2012 at 11:46 AM, Manuel López-Ibáñez
>> <lopeziba...@gmail.com> wrote:
>>> On 10 April 2012 00:28, Jason Merrill <ja...@redhat.com> wrote:
>>>> On 04/09/2012 04:01 PM, Manuel López-Ibáńez wrote:
>>>>> * It uses  the default cutoff as max_width, whatever it is (as
>>>>> controlled by -fmessage-length).
>>>>> * It uses the pretty-printer. The text cannot (should not) wrap
>>>>> because we still print only max_width chars at most.
>>>> Hmm, I think if pp_line_cutoff is 0 and we're on a terminal, we still want
>>>> to use COLUMNS to limit how much of the source we print.
>>> Like this?
>> There is a novelty in this new version that I don't think we discussed
>> before: automatic expansion of tabs to 8 hard space characters.  That
>> number should not be hardcoded as there is no reason to believe a tab
>> character always expands to 8 space characters.  You should check
>> the environment first; if not present the default expansion number should
>> be a symbolic constant as opposed to a magic number sprinkled all over the
>> places.  I would also encourage you to introduce more abstraction to
>> reduce the size of diagnostic_show_locus.
> Knobs have a cost.  Having 1000s of command line options doesn't really make 
> a product better.  Our job is to provide what we must and omit what we can.  
> You argue for a knob that no user has asked for or expressed a need for.  I 
> think we should have a much higher bar than this.  The reality is, tabs are 
> 8, period.  There was a time went editors managed tabs stops by changing 
> column into which a tab would move, this ability taken from devices called 
> typewriters which had a little metal bit that you moved around where you 
> wanted tab stops.  The days of there devices called typewriters are over, we 
> no longer cater to them.  Today, editors can manage what the key called TAB 
> does, and its semantics are disconnected from the file save format.  This 
> file format can be set at 8, while the edit function is indent 2, 4, 8 or as 
> complex as what emacs does with c-mode.  It is a bad idea to have a file 
> format tab is other than 8, and we should encourage all but legacy people to 
> convert to 8.  We do this by having a wiki entry and explains the use of pr, 
> and how to set the file save format to 8, if we need to.  For legacy people, 
> they don't _want_ a new compiler, pretty much by definition.  So, I'd argue 
> for a symbol constant, but, a constant nonetheless.  If a large user _had_ 
> serious needs for something other than 8, _they_ can change the compiler to:
>  #define TAB_COLS (getenv("TABS") ? atoi (genenv("TABS")) : 8)
> if they want.  I don't think we should have a knob for this.

This is fully mystifying to me and I still do not understand what it
is all about after reading it 8 times.

- Gaby

Reply via email to