Parse Tree Display Improvements

[elgertam]

• Use display: none to remove non-displayed pexpr nodes from DOM (better performance & the hidden parse nodes take up no screen space)
• Modified CSS for bottom pane
  • Preserved behavior where pane cannot be shrunk smaller than displayed parse tree
  • Added scrolling (x & y directions) when parse tree's height exceeds available screen size

I recently wrote a grammar for C in Ohm. The editor is wonderful, but I ran across a couple of annoyances while using it. The first was that I could not scroll down when a parse tree exceeded the size of the bottom pane. Since C can have quite large parse trees, this was problematic. Second, while stepping through a parse, I noticed a bunch of extra whitespace at the bottom of the pane below the current parse node. This was due to visibility: hidden, which only hides a node but doesn't remove it from the DOM.

I made a few simple changes to the CSS (summarized at the top), and now scrolling works while also not shrinking the bottom pane smaller than the maximum content height. I tested these changes in Chromium & Firefox.

(I still have one more that requires a more in-depth examination: namely, traversing deeply nested left-recursive productions creates an exponential number of parse nodes to visit. I'd prefer to display the memoization that Ohm is doing to move through LR nodes the way Ohm itself does. Once I get around to that, I'll make another PR.)

[pdubroy]

Thanks for the PR!

I gave this a try locally (checking out the branch and running npm start) and I'm seeing some odd behavior when I try to make the parse tree pane smaller:

https://user-images.githubusercontent.com/17293/150536087-66d1a170-788b-4b8f-864b-a83e8d86cc3a.mp4

As I click and start dragging, the pane immediately grows bigger. I don't see the same thing on tip of master.

[elgertam]

Thank you for the consideration!

I noticed similar behavior and haven't had a chance to properly debug. However, I do have a hunch. I noticed that flex-grow is used to control the height of the bottom pane. I'm guessing that is responsible for the odd "jumping" behavior, though I can never be totally certain where CSS is concerned. I can take some time today to figure it out.

[elgertam]

Hi @pdubroy, I wanted to give a quick update. That odd behavior is indeed due to the pane heights being set using flex-grow. However, simply changing it to use height or pixels/percentages or something is easier said than done.

As far as I can tell, the behavior should be something like this: always display as much of the user-expanded parse tree as possible, and always display at least one of the examples in the top-right pane. When there is free space, the user can resize the panes, but when there isn't, the panes are fixed and the user must scroll or collapse parse tree nodes.