The "di as error" style sometimes persists & affects the next "di" command...why?

[Dale Rhoda]

I know that "Consistency is the hobgoblin of small minds" so this is not a burning issue, but a point of mild curiosity in the interest of writing parsimonious code.

In our work, we write a lot of .ado files and we often use the display command to send informative messages to the screen / log.

When we want the message to appear in a red font, we use 'display as error'. And for black we often (lazily) use the display command without specifying a style. This works as expected in interactive mode, as demonstrated in Example 1 in the screenshot below.

But sometimes inside loops & programs the 'as error' style seems to carry over or persist from one display command to another when we did not intend that. See Example 2 in the screenshot below.

The problem is easily addressed: Always specify the style explicitly...as shown in Example 3 below. But I am curious whether the persistence of the error style is intentional and curious about how I can identify situations where I can confidently get away with typing di without specifying the style. I would naively and lazily prefer each new simple 'di' command to be a synonym for 'di as text'. But I cannot count on that working everywhere.

Again...not a burning issue, but if there's a clear explanation, I'd love to be enlightened.

Thank you,
-Dale

[Nick Cox]

I thought the quotation was something like "A foolish consistency..." but then again from this viewpoint Emerson seems to have been something of a windbag and stronger on rhetoric than logic.

I can't copy and paste from a screenshot (please see FAQ Advice #12 on this point; I realise that showing red was the main point) and I am too lazy to retype your code. I will just agree that what you show shouldn't happen. On the evidence you've given, there is a small bug in display.

[Dale Rhoda]

Thanks, Nick...here is copy/paste code.

* Example 1: Interactive lazy di

di as error "This is an ERROR"
di "This is NOT"

* Example 2: Put the lazy example inside a loop

forvalues i = 1/3 {
di as error "This is an ERROR"
di "This is NOT"
}

* Example 3: Specify style explicitly in the loop

forvalues i = 1/3 {
di as error "This is an ERROR"
di as text "This is NOT"
}

[Clyde Schechter]

FWIW, I encountered this same phenomenon very early in my Stata use, probably back at version 4. So if this is to be viewed as a bug, it has been around for a very long time! What I didn't know until now is that the behavior is different when not inside a loop! I had always assumed that it was a "feature" that once -display as error- is used, the red color remains in effect until explicitly cancelled by a -display as text' command. And I have always been explicitly about display style in using -display- commands.

Anyway, what I'm trying to say in an excessively long-winded way, is that I think having the style persist until cancelled makes sense as a design decision. But what has to be counted as a bug is having the behavior inconsistent, depending on whether one is inside a loop or not.. II think StataCorp should fix this inconsistency. What's not at all clear is which way they should fix it!

[Nick Cox]

Thanks; I confirm the results shown in Stata 15 (for Windows, not that I expect that's important).

[Dale Rhoda]

StataCorp tells me they are taking a look...they wonder if it's maybe a problem with the forvalues command. I get the same result inside a foreach loop, too.

[Jeph Herrin]

Like Clyde, I have seen this behaviour for many versions of Stata, though in my case it has always been "di in y" that persists. When programming nice output I often use yellow type to highlight certain values (an idea borrowed from classic Stata color scheme), and have many times had to specify "di in g" to reset the color.

[Clyde Schechter]

Well, my experience with this actually goes back to versions of Stata that didn't yet have -foreach- or -forvalues-. The same thing happens with a -while- loop:

. local i = 1

. while `i' <= 3 {
  2.         display as error "This is an Error"
  3.         display "This is not"
  4.         local ++i
  5. }
This is an Error
This is not
This is an Error
This is not
This is an Error
This is not