Every place there is some depth that increases by one, there should be another place that decreases the depth by one.

Where is that?

If the tat is not LeftRowBox then we never reach the decrement.

You are saying something more or less like what the code says. Why is the decrement not reached. What is the depth used for?

You are saying something more or less like what the code says. Why is the decrement not reached. What is the depth used for?

The deep was used to handle nested expressions like \( a b \( InputForm \` \(OutputForm \` c d\) e \) \)

When a \` is found, then the previous tokens are collected, and evaluated as a Symbol, a Box expression or StandardForm if there is no token before \`. The result of this step is stored in a variable, to be used as the second argument of FormBox.
Then, a new call to the method is done, with FormBox as a tag. In the new call, the next elements are processed until the bracket and box deeps reach 0. Then, these elements are collected into a String or a RowBox. Then, the instance where \` was found takes the format and the other collected elements, builds a FormBox[], and returns it (before reaching the line where the decrements happen).

I tried to find a way to put the increment and the decrement together, but it just was more involved than this approach: I should have allowed the increment of the deep variables, and then doing the decrement before returning the FormBox. I didn't think that it was clearer.

I hope the new comment helps to understand the logic.

Thanks for the description. Something about this seems a little to complicated and that there should be something that follows the specification in a little more direct way:

• In InputForm and StandardForm, (form∖`input∖) yields FormBox[input,form].
• ∖(∖`input∖) yields FormBox[input,RawForm].

I would like to think about and reflect on this some more. I think we can make this cleaner, clearer and simpler.

What would be ideal is if we could do a cleanup step first - no changes to behavior yet.
Then add the list of tests that are wrong and that we want to fix.

And after this, then come up with a way to implement this.

• ∖(∖`input∖) yields FormBox[input,RawForm].

Actually, in WMA,

In[1]:= \(\`input\)                                                             

Out[1]= FormBox[input, StandardForm]

I would like to think about and reflect on this some more. I think we can make this cleaner, clearer and simpler.

I am sure it is possible, just that after trying for a while, I didn't find a better way.

What would be ideal is if we could do a cleanup step first - no changes to behavior yet. Then add the list of tests that are wrong and that we want to fix.

What would be a cleanup step? The list of (simple) tests to check are the tests that I added in test/core/parser/test_parser.py.

And after this, then come up with a way to implement this.

OK, in that case, I am going to put this as a draft for a while.

Why was this removed?

Because with the current logic, to implement the behavior of FormBox is not possible using this mechanism, so in my proposal, this method is never used.

Yes, this is what I mean about the myopic kind of thing. FormBox needs to worry about precedence and the b_ routines are where this kind of thing is done. So if you are defeating that, then maybe the thinking around this is flawed.

Yes, I was aware about the possible issue with the precedence. So I checked it against WMA, and it also seems to neglect the operator precedence of \`, so it gives the maximum precedence to it. On the other hand, the tokens that follows \` are processed using all the precedence rules.

What makes me think that this is the right approach (or at least a better approach than the current one) is that it does not break the existing tests, and it just makes a difference if a \` token is found inside a LeftRowBracket/RightRowBracket expression.