Reputation
8,156
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
29 52
Newest
 Custodian
Impact
~33k people reached

Jun
26
comment Reference to multiple stylesheets
That having been said, your statement that multiple stylesheets "don't work" is not strictly true. They don't work for your purposes. But they do work. You can use multiple StyleData[StyleDefinition->...] cells to mix in new styles. So if, in your example, "StyleSheet2.nb" has styles which don't exist in "StyleSheet1.nb", then they will be amalgamated together in your new stylesheet. So it does do something, just not what you were hoping for. Sorry for the multiple commenting, but I don't feel like I'm actually answering your question. Unless you'd accept "no" as an answer. :)
Jun
26
comment Reference to multiple stylesheets
...and these particular computations, although we cache them as much as possible, are one of the most expensive computations in the system. Not to mention the amount of effort to implement which, as has been pointed out in this thread, has a very low payoff because very few people would ever use this feature.
Jun
26
comment Reference to multiple stylesheets
If I have two versions of "Title" inherited from different stylesheets and they define FontColor differently, it is no longer acceptable for me to just take the first one. I must figure out where the information came from for each style. If both stylesheets inherit from Default.nb, but only the second stylesheet overrides Default.nb's version of FontColor, then I must choose the second. If only the first overrides, then I must choose the first. This necessity to not just track option settings, but the precise provenance of each and every option setting is expensive...(continued)
Jun
26
comment Reference to multiple stylesheets
The multiple inheritance problem is not to be dismissed. Styles can be "re-rooted" (effectively told to ignore inheritance) by using StyleData[name, StyleDefinitions->None]. So, let's assume you have multiple stylesheets which inherit from Core.nb. Each one of them defines a new "Input" style. Some re-root "Input" and others don't. What to do? Also, the multiple inheritance problem introduces serious performance issues...(continued)
Jun
9
comment Faded output is printed from dynamic object
@MarcoB, set the aforementioned option setting on $FrontEnd. I.e., CurrentValue[$FrontEnd, {PrivateCellOptions, "EvaluationUnmatchedStyle"}] = {}
May
26
awarded  Custodian
May
26
reviewed Approve ParallelTable and global variables
Apr
28
awarded  Necromancer
Apr
23
answered Asynchronous evaluation on EventHandler
Apr
16
awarded  Nice Answer
Apr
14
awarded  Necromancer
Apr
13
awarded  Revival
Apr
13
comment Faded output is printed from dynamic object
@IstvánZachar since v6 grouping constructs can now be applied without setting CellGrouping->Manual. What the Cell->Cell Grouping->Group Together menu command does is to apply a style which causes automatic grouping to work in exactly the way you want. And then the Group Normally menu command just clears that style information. While this is not strictly as powerful as manual grouping, it is sufficiently flexible to handle pretty much every real-world concern. And because it's done via styles, it's much less fragile than manual grouping, which is the source of lots of bugs.
Apr
13
answered Faded output is printed from dynamic object
Apr
6
comment Faded output is printed from dynamic object
Why do you use CellGrouping->Manual? What are you trying to achieve that you can't achieve other ways? I've seriously considered deprecating manual cell grouping (since it's easy to manually group cells under automatic grouping), and I'd like to understand what you find interesting about it.
Mar
28
awarded  Pundit
Mar
22
awarded  Guru
Mar
10
awarded  Nice Answer
Jan
30
awarded  Yearling
Jan
9
awarded  Good Answer