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.
