This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Caret diagnostics

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
> <> wrote:
>> On 10 April 2012 00:28, Jason Merrill <> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]