Auto bracket improvements

[JMSS-Unknown]

Now brackets are shown when the previous character is a number.
E.g. Typing 12(12)^2 now explicitly renders the brackets but ab^2, 12+12^2 or 12*12^2 does not.

This fixes #135 but when importing the syntax tree, the multiplication becomes hidden.
E.g. 3*10^8 becomes 3(10)^8. I guess this is expected as the syntax tree does not contain this information. Maybe there should be another symbol, like mul_implicit to differentiate the two?

[daniel3735928559]

Provisionally, this seems to work great--even on things like 2(4)^{3(5)^2}. I'd like to think through the edge-cases of this a little, and maybe add some tests to make sure this covers them, but if the problem is entirely encapsulated in "adjacent numbers in a symbol and non-symbol".

[daniel3735928559]

One edge-case that comes to mind is (and this is not proper notation at all, but still): definite_integral(1, 2, x, 2)4 renders as int_1^2 x d24 when perhaps it should render as int_1^2 x d(2)4.

The problem is if you require, say, no adjacent numbers either before or after, then 2^3 4 will get brackets when it shouldn't.

Perhaps the right thing to do in the case of adjacent numbers like this is to bracket the entire symbol, so 12(12^2) or (int_1^2 x d2)4.

[daniel3735928559]

On second look, this PR also causes 4int_1^2 x d2 to render brackets around the 2. Realistically, what it should probably do is only apply to e nodes with bracket="yes" if their LaTeX template reference has appears at the beginning and they are preceded by a number, or at the end and they are followed by a number.

For example, the LaTeX rendering for integral is \int {$1} d{$2} and the {$2} appears at the end, so it should be checked that the second c node ends with a number and that the whole symbol is immediately followed by a number. Likewise, exponential renders as {{$1}}^{{$2}}. Here, {$1} doesn't literally appear at the beginning of this string, however the stuff before it is non-rendered (unescaped {), so the first c node should be checked for numbers at the beginning (along with bracket="yes" and numbers immediately before the symbol).

auto_bracket does happen pretty deep inside the inner-most loop of the rendering process, which means making this routine expensive has the potential to impact performance visibly, at least on mobile, so it probably merits some care.

If you want to try morphing this PR into something that addresses the above concerns, this is fine, but I realise it is a tall order and have mostly left this as a musing to return to when I next get time to code on this.

I appreciate both the attempt and driving forward the business of fixing this issue.

[JMSS-Unknown]

Thanks for the comments.

Another thing that might be required to check, is to see if the node with the auto bracket and the corresponding node before or after it contains the same value for small. For example with the exp symbol, the {$2} never needs to be bracketed if there are numbers after it as it has a higher baseline. Although, the {$2} doesn't actually have bracket="yes" so I don't know if this is an actual issue. I also can't think of any symbols where they would have both properties so maybe this doesn't matter.

Feel free to close this PR when you get around to implementing a proper fix. I doubt my way of trying to implement your comments would be ideal, so I will refrain from modifying this PR.

[daniel3735928559]

Yeah, I think it's even subtler than I'd thought at first; e.g. imagine 4int_1^2 x d2 2^4 in which case you want to bracket at least one if not both of the 2s, but may need to go decently deep in the tree to become aware of this. This can of course be done, but will take some work.

Another edge-case, which may raise the small issue you bring up, is if there were a symbol with LaTeX rendering {}^{{$1}}{{$2}}, in which case preceding this with an exponent will result in something potentially ambiguous even if $1 is not just a number.

Another, perhaps simpler option, for those cases is that blank e nodes are rendered in LaTeX with a small amount of horizontal space.

At any rate, I'll work on it but will leave this PR open as a way of tracking the various ideas/issues around this problem and then close when it's resolved.

[JMSS-Unknown]

I thought of another option that would only work for the exp symbol. It would be to consider the exp symbol like the multiply symbol in that the what's left and right of the multiply symbol aren't actually its children, even though they technically belong under it. I presume it is done like this so that it makes it easy to break out of the multiply symbol by, for example, typing a plus in front of it and have to manually group text together with parenthesis if otherwise implied. This same concept can be applied to the exp symbol and would involve making the symbol only have one input like so, "^{{$1}}" and letting the parser group it together correctly.

[saivan]

That sounds like a good idea, it should work!