1

Bug introduced in V11.1 or earlier and persists through V11.3

[CASE:4061571], confirmed

Consider the following three examples of a cell:

CellPrint@Cell["i", "Section"]
CellPrint@Cell[BoxData@InterpretationBox[Cell@"i", 2], "Section"]
CellPrint@Cell[BoxData@InterpretationBox[Cell@"i", 2], "Section", "Section"]

which yields:

Mathematica graphics

Notice how the second cell has some strange mixture of styles applied. According to the documentation of Cell:

Cell[contents,"style1","style2",…] represents a cell with multiple styles applied to it.

So there should be nothing special about the third line.

While I am pretty sure that this is a bug, I have noticed that the documentation pages all do the same thing for their heading cells:

Cell[
  TextData[{…,"Basic Examples",…}],
  "ExampleSection",
  "ExampleSection",
  WholeCellGroupOpener->True
]

So I'm not so sure anymore where the issue lies. This brings me to the purpose of this question:

  • What is happening in the second/third example?
  • Why are only some styles applied, but not others?
  • Why is the reasoning behind applying the same style twice? (and why does it make a difference?)
  • Is this behavior documented anywhere?
Community
  • 1
Lukas Lang
  • 33,963
  • 1
  • 51
  • 97
  • 1
    I'd report this one too. Are you planning to do so with those 3 topics? – Kuba May 01 '18 at 19:48
  • @Kuba already did (I'll update the posts once I get an answer) - I know that this is not the place to post bug reports, but I figured I'd post them anyway in the hopes of getting more insight and possibly a workaround. Also, I'm still not too used to working with Cell and Box expressions, so I assumed there's a significant chance that I've simply missed something in the docs ;) – Lukas Lang May 02 '18 at 07:42
  • It depends, I'm posting 95% of bugs I find because it may help future readers, I also want to put pressure on WRI but I don't hope for much :). It is good to know something is a bug and not e..g your lack of knowledge. – Kuba May 02 '18 at 08:00
  • 1
    You can kinda think of your multi-style specification as more like {"Section", styles dictated by the FrontEnd, "Section", ...}. An example of a style that the FrontEnd can inject is "StandardForm"/"TraditionalForm". It's not that simple, but that is the general gist. – ihojnicki May 02 '18 at 20:08
  • @ihojnicki do you have any reference for this with a bit more information about what's going on? – Lukas Lang May 02 '18 at 20:45
  • @Mathe172 I would be surprised if that particular behavior was described anywhere. – ihojnicki May 03 '18 at 02:31
  • @ihojnicki That's unfortunate, but I was afraid you'd say something like that... All the more thanks to you in that case! – Lukas Lang May 03 '18 at 06:51
  • 1
    @ihojnicki and Mathe172 I'd say it is explicitly against StylesAndTheInheritanceOfOptionSettings which sets the hierarchy quite clearly. I can live with 'hidden' styles (for DocekdCells/InlineCells) and the fact that they are inserted between Cell's and Notebook's options but in this case they are inserted between Cell's styles making the first style very special. The discussion about documenting all those exceptions is not new. Maybe there is no huge demand, or maybe there is no demand because people are discouraged by apparent randomness? – Kuba May 03 '18 at 10:30
  • 1
    @Kuba Interesting... I didn't know about that post by John. Which by the way is the answer to this question. In the example above, its step two that causes the difference in appearance. – ihojnicki May 03 '18 at 11:36
  • @ihojnicki you are right, I missed that even though I knew. (otoh unless you see the source code you could argue that step two could 'patched' by 9th anyway) – Kuba May 03 '18 at 11:48
  • @Kuba thanks a lot for the link! That does indeed explain what's happening here. I've voted to close this question as a duplicate - if the vote doesn't pass, I'll probably add a short answer based on the linked one (if I don't forget) – Lukas Lang May 05 '18 at 11:23

0 Answers0