www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD now has colorized syntax highlighting in error messages

reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 14 2017
next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 14 May 2017 at 14:07:20 UTC, 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.


Thanks a lot. In my opinion these kind of changes are small but 
have huge impact on the acceptance of a language.

Kind regards
André
May 14 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/14/2017 9:04 AM, Andre Pany wrote:

 Thanks a lot. In my opinion these kind of changes are small but have huge
impact
 on the acceptance of a language.


I agree. A couple other improvements needed for error messages:

1. print out the offending line

2. have a clickable link to a more exhaustive explanation on dlang.org

Anyone interested in taking either of these on?
May 14 2017
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-05-14 18:25, Walter Bright wrote:


 1. print out the offending line


I hope this one will be optional/configurable. I don't think it 
necessary to print the offending line within an editor/IDE. They usually 
can already map the error to the offending line.

-- 
/Jacob Carlborg
May 14 2017
parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 14 May 2017 at 17:54:38 UTC, Jacob Carlborg wrote:

 On 2017-05-14 18:25, Walter Bright wrote:


 1. print out the offending line


 I hope this one will be optional/configurable. I don't think it 
 necessary to print the offending line within an editor/IDE. 
 They usually can already map the error to the offending line.


Yes +1 for configurable. IDEs already parse and make things 
clickable.
It's not just +1, it's mandatory. If you implement this you must 
add a new compiler switch.
May 14 2017
next sibling parent cym13 <cpicard openmailbox.org> writes:
On Sunday, 14 May 2017 at 19:11:32 UTC, Basile B. wrote:

 On Sunday, 14 May 2017 at 17:54:38 UTC, Jacob Carlborg wrote:

 On 2017-05-14 18:25, Walter Bright wrote:


 1. print out the offending line


 I hope this one will be optional/configurable. I don't think 
 it necessary to print the offending line within an editor/IDE. 
 They usually can already map the error to the offending line.


 Yes +1 for configurable. IDEs already parse and make things 
 clickable.
 It's not just +1, it's mandatory. If you implement this you 
 must add a new compiler switch.


Can't the IDE remove the line itself if it troubles him? I don't 
think such a small thing should burden the compiler with a flag 
just for the sake of a tool.
May 14 2017
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 14 May 2017 at 19:11:32 UTC, Basile B. wrote:

 Yes +1 for configurable. IDEs already parse and make things 
 clickable.
 It's not just +1, it's mandatory. If you implement this you 
 must add a new compiler switch.


No problem, it could only print out the line if the output is a 
terminal, same as for how it decides whether to output colors by 
default.
May 14 2017
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Sunday, 14 May 2017 at 23:17:42 UTC, Vladimir Panteleev wrote:

 On Sunday, 14 May 2017 at 19:11:32 UTC, Basile B. wrote:

 Yes +1 for configurable. IDEs already parse and make things 
 clickable.
 It's not just +1, it's mandatory. If you implement this you 
 must add a new compiler switch.


 No problem, it could only print out the line if the output is a 
 terminal, same as for how it decides whether to output colors 
 by default.


Yes that another option. But maybe my answer was a bit excessive. 
Let's wait and see how it looks.
May 14 2017
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-05-15 01:17, Vladimir Panteleev wrote:


 No problem, it could only print out the line if the output is a
 terminal, same as for how it decides whether to output colors by default.


Ah, that would be fine.

-- 
/Jacob Carlborg
May 15 2017
prev sibling parent MysticZach <reachzach ggmail.com> writes:
On Sunday, 14 May 2017 at 16:25:36 UTC, Walter Bright wrote:

 On 5/14/2017 9:04 AM, Andre Pany wrote:

 Thanks a lot. In my opinion these kind of changes are small 
 but have huge impact
 on the acceptance of a language.


 I agree. A couple other improvements needed for error messages:


In the PR you say that someone with a better color sense ought to 
choose the default colors. I don't have such a sense myself. But 
I recognize that as a real task for which help should be sought. 
Maybe this thread is a good place to get a volunteer?
May 14 2017
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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.


sorry for being rude, but this is exactly the example of things programmers 
like to write: fun, quite easy, and absolutely useless. most of the time it 
will be filtered away by ide/editor, and otherwise it is *harder* to read, 
'cause it will almost certainly not match editor's syntax coloring settings, 
so reader will have to mentally strip the colors first.

while much harder task -- showing which exactly template failed in template 
constraint -- is very hard to implement (i tried it, i know it), but will 
immediately benefit *anyone*, and will be really useful.

i'm not trying to say that you should drop the things you like to work on, 
and switch to the things i like, of course. but this patch, IMO, doesn't 
deserve a dedicated NG post.

sorry again, i'm frustrated by dmd inability to generate valid .o file from 
completely valid source, so can be harsh today.
May 14 2017
next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Mon, 2017-05-15 at 05:44 +0300, ketmar via Digitalmars-d-announce
wrote:

=20


[=E2=80=A6]

 sorry for being rude, but this is exactly the example of things
 programmers=20
 like to write: fun, quite easy, and absolutely useless. most of the
 time it=20
 will be filtered away by ide/editor, and otherwise it is *harder* to
 read,=20
 'cause it will almost certainly not match editor's syntax coloring
 settings,=20
 so reader will have to mentally strip the colors first.


Also the default colours chosen by the developer usually work well for
the them and their (and if you are lucky reviewers) terminal settings
and are totally useless for a huge section of using audience (most of
whom remain silent for various reasons). Take Git for example. I end up
having to run:

git =E2=80=A6 | more

to get rid of the colours. The default colours might work for the Git
developers but fail dismally for me. I cannot be bothered to get into
the detail of how to change the Git colouring so I use more to get rid
of it.=20

I like having colours, for exactly the same reason colouring is good in
source code editing, they can apply semantic (albeit often syntactic)
coding, but all too often the colour choices are dreadful and too
difficult to change. Hence all too often I have to:

emacs --color=3Dno

I still like colouring, it is just that mostly it is done for a given
terminal setting, and/or in a way too difficult to change locally.


 while much harder task -- showing which exactly template failed in
 template=20
 constraint -- is very hard to implement (i tried it, i know it), but
 will=20
 immediately benefit *anyone*, and will be really useful.
=20
 i'm not trying to say that you should drop the things you like to
 work on,=20
 and switch to the things i like, of course. but this patch, IMO,
 doesn't=20
 deserve a dedicated NG post.
=20
 sorry again, i'm frustrated by dmd inability to generate valid .o
 file from=20
 completely valid source, so can be harsh today.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 14 2017
parent Jacob Carlborg <doob me.com> writes:
On 2017-05-15 05:06, Russel Winder via Digitalmars-d-announce wrote:


 Also the default colours chosen by the developer usually work well for
 the them and their (and if you are lucky reviewers) terminal settings
 and are totally useless for a huge section of using audience (most of
 whom remain silent for various reasons). Take Git for example. I end up
 having to run:

 git … | more

 to get rid of the colours. The default colours might work for the Git
 developers but fail dismally for me. I cannot be bothered to get into
 the detail of how to change the Git colouring so I use more to get rid
 of it.


If you want to completely remove the colors in the Git output, add this:

[color]
     ui = off

To ~/.gitconfig

-- 
/Jacob Carlborg
May 15 2017
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 14 2017
next sibling parent Russel Winder via Digitalmars-d-announce writes:
On Sun, 2017-05-14 at 20:09 -0700, Walter Bright via Digitalmars-d-
announce wrote:

 On 5/14/2017 7:44 PM, ketmar wrote:

 sorry for being rude,


=20
 Then please do not post rude comments. We expect professional decorum
 here.


But in politics lying and being rude is completely the norm. Also, as
yet, software development is not a profession. I think "respect for
others" and "empathy" are better lines to take.=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 14 2017
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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.
May 14 2017
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
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...

/P
May 15 2017
parent Joakim <dlang joakim.fea.st> writes:
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.
May 16 2017
prev sibling parent "H. S. Teoh via Digitalmars-d-announce" writes:
On Mon, May 15, 2017 at 04:06:29AM +0100, Russel Winder via
Digitalmars-d-announce wrote:
[...]

 Also the default colours chosen by the developer usually work well for
 the them and their (and if you are lucky reviewers) terminal settings
 and are totally useless for a huge section of using audience (most of
 whom remain silent for various reasons). Take Git for example. I end
 up having to run:
 
 git … | more
 
 to get rid of the colours. The default colours might work for the Git
 developers but fail dismally for me. I cannot be bothered to get into
 the detail of how to change the Git colouring so I use more to get rid
 of it. 


	git config --global color.ui false

I sure hope this is also configurable with dmd, otherwise I may find
myself having one less reason to use it.



 I like having colours, for exactly the same reason colouring is good
 in source code editing, they can apply semantic (albeit often
 syntactic) coding, but all too often the colour choices are dreadful
 and too difficult to change. Hence all too often I have to:


[...]

I hate colors, for the reason you stated above: they usually clash with
my choice of terminal default color settings.  Also, I find colors a big
distraction to the eye when I'm trying to focus.  I don't even like
syntax highlighting for that reason. My take on it is that if I can't
parse the code with a glance, then either (1) my grasp of the language
is so poor I really shouldn't be coding in that language, or (2) the
code is so unreadably poorly-formatted it's time to fix the formatting
before proceeding any further.


T

-- 
Skill without imagination is craftsmanship and gives us many useful objects
such as wickerwork picnic baskets.  Imagination without skill gives us modern
art. -- Tom Stoppard
May 14 2017
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Sunday, May 14, 2017 21:07:57 H. S. Teoh via Digitalmars-d-announce 
wrote:

 I hate colors, for the reason you stated above: they usually clash with
 my choice of terminal default color settings.  Also, I find colors a big
 distraction to the eye when I'm trying to focus.  I don't even like
 syntax highlighting for that reason. My take on it is that if I can't
 parse the code with a glance, then either (1) my grasp of the language
 is so poor I really shouldn't be coding in that language, or (2) the
 code is so unreadably poorly-formatted it's time to fix the formatting
 before proceeding any further.


LOL. To each their own. I remember a coworker who never used colors with
vim, and I found it really hard to read his screen. Even if it's not
necessary, I find that having syntax highlighting really helps, and in some
cases it pretty much screams at you that you screwed up (e.g. unterminated
string literals). But it also depends on the colors. If the colors aren't
configurable, then it's pretty easy for it to be a big problem. There is no
"one size fits all" for colors, though some color schemes will work better
in general than others.

I haven't gotten the chance to look at the dmd error messages yet to see how
they look, but if the colors are decent, then I'd expect them to help a lot
of people (especially with more complicated error messages). But given that
it's the command line, I don't know how they'd be very configurable
(certainly not like you could do with an IDE), though as long as there's a
way to turn them off, then worst case, you end up with what we had before.

- Jonathan M Davis
May 15 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 15 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
May 15 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 15 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
May 15 2017
parent Jacob Carlborg <doob me.com> writes:
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
May 16 2017
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 14 May 2017 at 14:07:20 UTC, Walter Bright wrote:

 The only downside is now we have to rather tediously tweak the 
 error message texts so they use backticks.


It also dilutes the meaning of color. I've been wanting to see 
highlighted matches and failures in overload resolution and 
constraint checks (this has been on my todo list for a while 
since every attempt so far has failed; as I'm sure you know, it 
isn't trivial to implement in the current compiler). Such 
highlights would now have to compete with unnecessary syntax 
coloration; you can't visually scan for color anymore since it 
doesn't mean anything special.

Terminal color choices are also painful, though I kinda believe 
this is the terminal's fault. I ended up doing hacky code in mine 
to ensure a legible palette, but still, not everyone has done 
that.


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?
May 15 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 15 2017
parent Adam D. Ruppe <destructionator gmail.com> writes:
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.
May 15 2017
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
May 16 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
May 16 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 16 May 2017 at 14:04:34 UTC, Walter Bright wrote:

 With all the complaints about color, note that dmd already has 
 been using color in error messages for years with no complaints


My complaint isn't about the presence of color* but rather about 
the OVERUSE of it.

The old way of coloring the message header helps you quickly find 
the beginning of an error among output spam. It stands out. But 
now, with color being all over the place, you can't visually scan 
for it anymore. It loses its special meaning.

Similarly, what I want to see in the future is highlighting of 
specific parts of code where the error applies.

Error: No overload for foo(int), candidates are:
   foo(string);
   foo(int, string);

In my perfect world, `Error` is colored, like it is now, you can 
scan for it and find that. Then, the first `string` is also 
highlighted as a mismatch of the overload, and the `int` in the 
candidate signature is also highlighted as a match of the 
overload.

Then, your eyes can just look for the color and realize which 
candidate is the best match and immediately see what you're 
missing.



With syntax highlighting though, string and int will be 
highlighted as types or keywords... which is irrelevant to the 
issue of matching the correct overload. It stands out, but means 
nothing. And if everything is colored, yikes, then nothing stands 
out since you can't even eye scan it at all.



So again it is NOT color that bothers me. It is OVERUSE of color 
for stuff that isn't important to read the message which dilutes 
the meaning of color. It isn't special anymore.



* I did hate it for a while though because the contrast was poor, 
but I fixed that with some hack to my terminal emulator code to 
give it a superior adaptive palette. Perhaps tilix's author will 
want to do this too: mine has a different yellow when printed on 
white than on black, different blue, different teal. The 
application outputs the same sequence but my thing is aware of 
the background and adapts. Even if the application tries to 
output unreadable stuff explicitly, my terminal emulator won't 
allow it.

Big, big win on my eyes.
May 16 2017
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2017 7:17 AM, Adam D. Ruppe wrote:

 So again it is NOT color that bothers me. It is OVERUSE of color for stuff that
 isn't important to read the message which dilutes the meaning of color. It
isn't
 special anymore.


Perhaps. I know I have some trouble distinguishing code from explanatory text
in 
error messages, particularly when the code looks like english, as in:

     error: undefined identifier maybe

Colorizing code distinguishes it from text.

The initial color choices I picked are garish on purpose, it's to try things 
out. I expect to change it to more muted ones (turn off the intensity bit at 
least). It's also possible to use underlining.

I'm working on the next PR that will auto-detect if Adam is running the 
compiler, and will highlight code with blinking text.
May 16 2017
next sibling parent reply "H. S. Teoh via Digitalmars-d-announce" writes:
On Tue, May 16, 2017 at 08:11:21AM -0700, Walter Bright via
Digitalmars-d-announce wrote:

 On 5/16/2017 7:17 AM, Adam D. Ruppe wrote:

 So again it is NOT color that bothers me. It is OVERUSE of color for
 stuff that isn't important to read the message which dilutes the
 meaning of color. It isn't special anymore.


 
 Perhaps. I know I have some trouble distinguishing code from
 explanatory text in error messages, particularly when the code looks
 like english, as in:
 
     error: undefined identifier maybe
 
 Colorizing code distinguishes it from text.


[...]

Simpler solution: print the identifier in quotes, e.g.:

     error: undefined identifier 'maybe'

There: instantly clear without needing any colors.


T

-- 
LINUX = Lousy Interface for Nefarious Unix Xenophobes.
May 16 2017
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2017 8:13 AM, H. S. Teoh via Digitalmars-d-announce wrote:

 Simpler solution: print the identifier in quotes, e.g.:

      error: undefined identifier 'maybe'

 There: instantly clear without needing any colors.


I know about the quotes. With longer message lines, they get lost.

To turn off color, just add:

    -color=off

to your dmd.conf file.
May 16 2017
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 16 May 2017 at 15:11:21 UTC, Walter Bright wrote:

     error: undefined identifier maybe

 Colorizing code distinguishes it from text.


What's important there? The generic syntax that you get from a 
syntax highlighter or the fact that it is the user input?

Drawing attention to `maybe` there is a good idea! But that's not 
because it is syntax highlighted, it is because that's the most 
important word in the message.

(btw I think it already has attention because of its placement, 
it doesn't need additional color. but the case I keep going back 
to, function overloading, puts important stuff in the middle of 
the message and that would be nice to stand out, as long as 
what's important - the mismatched arguments - are what stand out)


 It's also possible to use underlining.


Yeah, on some systems, but not really on Windows or even all 
linux terminals. Color has broader support, though you do want to 
be careful not to *depend* on color either.


 I'm working on the next PR that will auto-detect if Adam is 
 running the compiler, and will highlight code with blinking 
 text.


I'm afraid that won't work, my terminal emulator doesn't support 
blinking.

But if it detected it was me and outputted XML error messages, oh 
boy, I'd be excited about that! I honestly very much would love 
xml error messages.
May 16 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2017 8:25 AM, Adam D. Ruppe wrote:

 It's also possible to use underlining.


 Yeah, on some systems, but not really on Windows or even all linux terminals.
 Color has broader support, though you do want to be careful not to *depend* on
 color either.


I've never met an ASCII console that didn't support underlining. This includes 
the ones I used back in the 1970's, and includes the tty I designed and built 
myself for a class project. It includes DOS and Windows consoles.

Underlining enjoys much broader support than color does. Color became fairly 
ubiquitous rather late, in 1990 or so. The VT-100 control sequences have 
effectively replaced all the other ones.


 my terminal emulator doesn't support blinking


Then yours is a unique snowflake, as it's standard for VT-100 emulation (xterm).
May 16 2017
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 16 May 2017 at 15:38:53 UTC, Walter Bright wrote:

 It includes DOS and Windows consoles.


Only under specific circumstances. On the VGA hardware, underline 
shares a bit with blue and needs a register tweaked to make it 
visible (the default 16 color VGA text mode does NOT display the 
underline), and only worked on CJK multibyte output on Windows 
2000 through Windows 10.

Only recently, with the one of the updates to windows 10, was 
console underlining added to Windows for English text, as part of 
their Linux terminal compatibility flag (see: 
ENABLE_VIRTUAL_TERMINAL_PROCESSING).


 Then yours is a unique snowflake, as it's standard for VT-100 
 emulation (xterm).


It isn't really unique, rxvt treats it as bold and xterm can have 
it compiled out. I do recognize the sequence and even set the bit 
(see: 
https://github.com/adamdruppe/terminal-emulator/blob/master/term
nalemulator.d#L1724 ) but then ignore it on the drawing side since blinking is
a pointless distraction.

In practice, basic color support is pretty broad and reliable, 
given you remember that there's a human reading it who can't see 
poor contrast easily and a large percentage of them cannot 
reliably tell all colors apart. Underline, however, is not 
broadly supported by the computer console apis.
May 16 2017
prev sibling parent Jonathan M Davis via Digitalmars-d-announce writes:
On Tuesday, May 16, 2017 08:11:21 Walter Bright via Digitalmars-d-announce 
wrote:

 On 5/16/2017 7:17 AM, Adam D. Ruppe wrote:

 So again it is NOT color that bothers me. It is OVERUSE of color for
 stuff that isn't important to read the message which dilutes the
 meaning of color. It isn't special anymore.


 Perhaps. I know I have some trouble distinguishing code from explanatory
 text in error messages, particularly when the code looks like english, as
 in:

      error: undefined identifier maybe

 Colorizing code distinguishes it from text.

 The initial color choices I picked are garish on purpose, it's to try
 things out. I expect to change it to more muted ones (turn off the
 intensity bit at least). It's also possible to use underlining.

 I'm working on the next PR that will auto-detect if Adam is running the
 compiler, and will highlight code with blinking text.


LOL. Or you could have it just say:

"I'm sorry, Adam. I'm afraid I can't do that."

:)

https://www.youtube.com/watch?v=OEu4Iq5KL-Q

- Jonathan M Davis
May 16 2017
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 16 May 2017 at 14:17:41 UTC, Adam D. Ruppe wrote:

 Similarly, what I want to see in the future is highlighting of 
 specific parts of code where the error applies.



Fear me. I combined Walter's code with my own to form some kind 
of Voltron!

https://github.com/dlang/dmd/pull/6806
May 17 2017
parent MysticZach <reachzach ggmail.com> writes:
On Thursday, 18 May 2017 at 01:52:17 UTC, Adam D. Ruppe wrote:

 On Tuesday, 16 May 2017 at 14:17:41 UTC, Adam D. Ruppe wrote:

 Similarly, what I want to see in the future is highlighting of 
 specific parts of code where the error applies.



 Fear me. I combined Walter's code with my own to form some kind 
 of Voltron!

 https://github.com/dlang/dmd/pull/6806


I think the compiler's error design could use a complete 
overhaul. I'm wondering if it wouldn't be wise to start a new git 
branch for all changes to error messages. Call it 
`stderr.experimental` or something cute like that. The idea is 
that D won't break people's test code that checks error output 
until a more complete design has been worked out and approved of. 
I'm not in favor of or against this idea. I just wanted to 
propose it.
May 18 2017
prev sibling next sibling parent Mike James <foo bar.com> writes:
On Sunday, 14 May 2017 at 14:07:20 UTC, 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.


The next step is Color D...

https://github.com/narke/colorForth

-=mike=-
May 16 2017
prev sibling parent Random D user <no email.com> writes:
On Sunday, 14 May 2017 at 14:07:20 UTC, Walter Bright wrote:

 https://github.com/dlang/dmd/pull/6777

 It turned out to be unexpectedly easy to implement.


Nice.

But color highlighting should always be configurable (otherwise 
it's half done), because there are a lot of people who like 
colors, but can't distinguish between certain color combinations, 
because of a color disability. Or they might have poor displays 
or viewing conditions etc.

I guess this should be simple to add, just output the colors into 
an .ini file and read them back if the file exists.
May 16 2017