Define equations to always be inlined

[bmaclach]

To achieve explicit grouping, we define "intermediate" symbols (see #1120), however we currently have no way to tell Drasil that, rather than displaying the "intermediate" symbols where they are used, these equations should be inlined. For example, we want:

But what we currently have is:

where h^R and h^L are examples of the aforementioned "intermediate" symbols. The inlining should automatically add parentheses around the inlined equation, thus providing the desired explicit grouping.

[JacquesCarette]

The idea would be to create a way to attach display options to certain chunks (like h^R here), such as 'inline', that the renderers (html and latex) would use to inline things.

[Awurama-N]

hmm Okay, Please how could i go about this?
@JacquesCarette

[JacquesCarette]

I would like you to spend some time trying to figure that out on your own first. Spend the morning.

[Awurama-N]

Okay will do

[Awurama-N]

I followed the chain of links from this issue to different issues and here's what i've learnt so far:

After explicit grouping this:

slcHeightEqn :: Expr  
slcHeightEqn = 0.5 * (((inxi slopeHght) - (inxi slipHght)) +     ((inxiM1 slopeHght) - (inxiM1 slipHght))) 

is currently this

slcHeightEqn :: Expr
slcHeightEqn = oneHalf `mulRe` (sy sliceHghtRight `addRe` sy sliceHghtLeft)

The grouping was done with "intermediate symbols".

onehalf defined in math.hs, mulRe & addRe defined in expr.hs, and sliceHghtRight (representing intermediate symbol h^r) & sliceHghtLeft (representing intermediate symbol h^l) defined in Unitals.hs.

I initially thought I would be manually changing the equations to the "inlined" format, but i realize now that we would like Drasil to automatically show these equation types in the "inline" format?

I feel like i understand the issue more now & have learnt quite a bit about the situation but I'm not a 100 per cent clear on how to actually go in and make the changes to fix this issue.

[JacquesCarette]

Sorry for the lack of earlier response.

Your analysis of the problem is correct. So what you need to do is to figure out what type sliceHghtRight is. If it's just Expr, that's a problem. But it's likely not, and has room for adding various attributes to it. The first thing to do is to figure out what type it is, and what are the various classes that that type belongs to. We can then figure out where in that to add display attributes.

The other 1/2 of the problem is in drasil-printers. That needs to be changed so that when it looks up sliceHgthRight in the right place in ChunkDB, it finds that annotation, and uses it to inline the definition.

[Awurama-N]

@JacquesCarette if i'm not mistaken, i have found that sliceHghtRight and sliceHghtLeft do not have type Expr.

sliceHghtRight = uc' "h^R" (cn "heights of the right side of slices") 
  "the heights of the right side of each slice, assuming slice surfaces have negative slope"
  (sup (vec lH) lRight) metre

sliceHghtLeft = uc' "h^L" (cn "heights of the left side of slices") 
  "the heights of the left side of each slice, assuming slice surfaces have negative slope"
  (sup (vec lH) lLeft) metre

A question i had though was: in this situation is the type (sup (vec lH) lRight) metre or just metre?
After this i can continue with the investigation.

[JacquesCarette]

Good. That means that there is ample room to annotate them. I think uc' is a constructor for a Unital.

The unit is metre, and the symbol is sup (vec lH) lRight (i.e. lower-case h typeset as a vector, with a superscript lower-case 'right'). I think uc' the constructor defaults to type Real, which is why you don't even see the type.

[Awurama-N]

Oh okay thank you