On 5/15/2017 1:05 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
> I haven't gotten the chance to look at the dmd error messages yet to see how
> they look,

They're a little garish at the moment, but that's just to make sure it's working correctly. I expect to tune it a bit, especially once I fix the console color package to be more useful.

I eventually want to make the console color package into a generic module, it could improve a number of console apps.

On 5/15/2017 6:10 AM, Adam D. Ruppe wrote:
> Suppose I, or someone else, were to write a PR eliminating your syntax
> highlighting in favor of semantic highlighting - colorizing to add more detail
> about the error message instead of about the lexer's output. Will you accept it?

I'm glad this sparks interest in improving the error message display, this is good. I can't say I'd accept something given the handwavy description, you'll need to create examples of how it would look.

One thing I have noticed while doing this is how unhelpful many of the error messages are. Consider the first one in traits.d:

        error(loc, "size overflow for type `%s`", t.toChars());

What was the size, and what was the maximum size? The compiler has this information, but does not supply it in the message.

This is all low hanging fruit that anyone can help with.

On Monday, 15 May 2017 at 14:18:30 UTC, Walter Bright wrote:
> I eventually want to make the console color package into a generic module, it could improve a number of console apps.

FYI we already have a few D modules that do console color (among other things) like consoled or my terminal.d.

On Monday, 15 May 2017 at 14:31:20 UTC, Walter Bright wrote:
> I'm glad this sparks interest in improving the error message display, this is good.

I've been meaning to do this for years... I want overload resolution and template constraints to tell which conditions were passed, failed, and short-circuited. Colorizing them in the output (green for pass, red for fail, default for short-circuited, for example) is one of the candidates ideas I have for concisely displaying that information to the user.

Problem is just that the compiler discards those details before it gets to the error message display and keeping it up the call chain is non-trivial (or did, last time I tried to implement it).


> One thing I have noticed while doing this is how unhelpful many of the error messages are.

Indeed, D's error messages are awful and I'd prefer we all spend time improving this more than anything else: make overload and constraint messages readable. Make size errors tell index and length in all cases (compile and runtime). Make inferred attribute errors tell you where and why the inferrence didn't match expectations.

And yes, I've written about all this in bugzilla already.

On 5/15/2017 8:35 AM, Adam D. Ruppe wrote:
> On Monday, 15 May 2017 at 14:18:30 UTC, Walter Bright wrote:
>> I eventually want to make the console color package into a generic module, it
>> could improve a number of console apps.
>
> FYI we already have a few D modules that do console color (among other things)
> like consoled or my terminal.d.

I have console programs that do it, too. That's why such needs to be turned into a generic module, instead of constantly being reinvented.

On Monday, 15 May 2017 at 15:40:58 UTC, Walter Bright wrote:
> That's why such needs to be turned into a generic module, instead of constantly being reinvented.

What I'm saying is that it IS a generic module... in fact, there's several of them:

http://code.dlang.org/search?q=color

colorize, consoled, rainbow, and drlutil are all competing in this space. My terminal library (which is also included in the consoled dub package) is another.

Now, I don't think you should use a library for this. Basic console color output is trivial and not worth the cost of a dependency (especially not a fat one like mine, which is full-featured console stuff when you just need simple color)... but I also don't think you should add yet another module to do it out there in public.

On 2017-05-15 23:33, Adam D. Ruppe wrote:
> On Monday, 15 May 2017 at 15:40:58 UTC, Walter Bright wrote:
>> That's why such needs to be turned into a generic module, instead of
>> constantly being reinvented.
>
> What I'm saying is that it IS a generic module... in fact, there's
> several of them:
>
> http://code.dlang.org/search?q=color
>
> colorize, consoled, rainbow, and drlutil are all competing in this
> space. My terminal library (which is also included in the consoled dub
> package) is another.
>
> Now, I don't think you should use a library for this. Basic console
> color output is trivial and not worth the cost of a dependency
> (especially not a fat one like mine, which is full-featured console
> stuff when you just need simple color)... but I also don't think you
> should add yet another module to do it out there in public.

It could be added as a subpackage to the upcoming Dub file [1].

[1] https://github.com/dlang/dmd/pull/6771

-- 
/Jacob Carlborg

On 05/14/2017 07:07 AM, Walter Bright wrote:
> https://github.com/dlang/dmd/pull/6777
>
> It turned out to be unexpectedly easy to implement.
>
> The only downside is now we have to rather tediously tweak the error
> message texts so they use backticks.

Color is informative to humans, so I'm all for it. I agree with others that it may be hard to please everyone. Is it possible to use the default scheme of the terminal?

I had the good fortune of sitting with Chandler Carruth and other C++ people during dinner here at C++Now. We did talk about error reporting and although it's mostly agreed that clang's errors are a big improvement, Chandler said that no matter how short or informative, people still don't read error messages! I'm not surprised: people are people. (I'm one and proud of it. :) )

According to Chandler, Rust got this right: Apparently, Rust shows the code *first*, then the error message underneath it. Chandler said that this trivial change in error reporting has been transformative and now people are very happy with Rust's error messages.

Ali

On Monday, 15 May 2017 at 08:08:20 UTC, Paolo Invernizzi wrote:
> On Monday, 15 May 2017 at 04:33:39 UTC, ketmar wrote:
>> On Monday, 15 May 2017 at 03:09:09 UTC, Walter Bright wrote:
>>> On 5/14/2017 7:44 PM, ketmar wrote:
>>>> sorry for being rude,
>>>
>>> Then please do not post rude comments. We expect professional decorum here.
>>
>> sorry. i never got any money for using D, so i'm certainly not a professional ('cause professionals are the people which get payment for their work). sorry again for polluting NG with my unprofessional writings. i will stop doing that immediately after this post.
>
> Rude or not, I think ketmar is right...

He may be right that working on something harder like better error messages for template constraints would be more useful, but Walter likely needs to work on some easy stuff once in awhile too, and this colored syntax will help.  Git just enabled colored highlighting of branch commits for git log and I've found it useful.

I didn't think he was rude- he did say sorry several times in the original post, expecting this response for his criticism- but misguided to criticize this change, for not always matching the user's settings, and to always expect Walter to work on the hard stuff.  Everybody needs to mix in some easy stuff, including Walter I bet, to stay motivated and get some easy wins.

On 5/16/2017 1:07 AM, Ali Çehreli wrote:
> Color is informative to humans, so I'm all for it. I agree with others that it
> may be hard to please everyone. Is it possible to use the default scheme of the
> terminal?

With all the complaints about color, note that dmd already has been using color in error messages for years with no complaints, and there is this switch:

    http://dlang.org/dmd-windows.html#switch-color