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