Remove highlighting from secondary messages

[estebank]

Deemphasize the secondary messages so that all other highlights stand
out more.

[rust-highfive]

r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

[estebank]

I'm sure this might be controversial. There was a ticket asking for this that I couldn't find now.

I'm looking for feedback.

cc @nikomatsakis @GuillaumeGomez @jonathandturner @petrochenkov

[GuillaumeGomez]

Can you post the original look too please? So we can see the differences more easily.

[estebank]

Before:

After:

The original ask was when dealing with lifetime errors involving 'static:

Before:

After:

The highlighting makes the first note seem more important than it is (alternatively we could highlight notes merged to a span instead, but I want to reduce highlighting).

[GuillaumeGomez]

I don't have strong opinion in here. It allows to focus more easily on the other messages, which depending on what we want might be better or worse. So do we want to focus on help messages, attract users' attention to tips or do we want to keep the attention on the first/initial/main error?

[estebank]

My reasoning is that we're already using span_notes and notes as part of the same "narrative", while on the cli output we give span_notes a highlight but not to notes, incorrectly differentiating them. I think it is a bikeshed-ing argument in any direction, but I'd like us to be consistent.

So do we want to focus on help messages, attract users' attention to tips or do we want to keep the attention on the first/initial/main error?

For what is worth, many vocal users want less highlighting and to focus on the main message. The proposed output would train people that bold white is where to look for the main message.

[cramertj]

I have no strong opinions one way or another.
@bors r? @GuillaumeGomez

[GuillaumeGomez]

I'd just like to have at least @nikomatsakis or @jonathandturner's opinion before r+ing it.

[mark-i-m]

Personally, I think this is an improvement.

[sophiajt]

While I think the general rule of thumb to decrease the amount of bold is probably a good thing, to my eyes, this is a small step backward. Specifically, this problem spot seems to have gotten worse:

In the first version, it's easy for the eye to separate out the first message from the second. In the revision, these visually merge together, which takes a little longer to parse at first glance.

One way to work around this might be to remove the bold, but add in a blank line. I think @nikomatsakis and I settled on using bold so that we wouldn't use too much spacing out of lines, but perhaps it's worth exploring again?

[estebank]

The thing is that those three lines are actually part of the same narrative, so it doesn't seem right to differentiate them as highly as we currently are.

[pietroalbini]

Ping from triage! @nikomatsakis can you check in on this?

[estebank]

@nikomatsakis could you take a look at this? The diff is minimal, and the output change can be seen in the screenshots above.

The only remaining argument remaining is @jonathandturner's worry that multiple notes one after the other will be harder to read. I don't think that is the case, and that the current unnecessary differentiation between notes with spans and without them is more detrimental to readability than this PRs output.

[nikomatsakis]

I like it

[nikomatsakis]

I agree with @jonathandturner that this particular case is slightly worse but I also think those messages are bad and something we are trying to revamp in a major way for NLL. =)

[estebank]

@GuillaumeGomez what do you think? Should we merge this as is?

[GuillaumeGomez]

Like I said, it doesn't make much differences for me. I gave the two opinions I had on the question but both are fine for me. :)

[stokhos]

Ping from triage @estebank , we haven't heard from you, will you have time to look into this PR, in near future?

[estebank]

will you have time to look into this PR, in near future?

@stokhos I don't see what's left for me to do on the PR.

It allows to focus more easily on the other messages, which depending on what we want might be better or worse.

That is something to be done on a case by case basis.

So do we want to focus on help messages, attract users' attention to tips or do we want to keep the attention on the first/initial/main error?

I believe that we need to make it easier to read the errors. There are people that are driven towards the error message and others driven towards the labels. With this change we are removing the attention seeking highlight from the notes, which should only be used to further understand the error, not the entry point.

[stokhos]

Ping from triage! @GuillaumeGomez this PR needs to be moved forward.

[GuillaumeGomez]

Then I suppose it's good to go. Thanks @estebank!

@bors: r+

[bors]

📌 Commit ed5dcc3 has been approved by GuillaumeGomez

[bors]

⌛ Testing commit ed5dcc3 with merge d439d6cde2ca0afe1d6f56e2e494cd1b35f3d7a5...

[bors]

💔 Test failed - status-appveyor

[kennytm]

@bors retry

[bors]

⌛ Testing commit ed5dcc3 with merge 0ad6179...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: GuillaumeGomez
Pushing 0ad6179 to master...