GitHub user zyratlo added a comment to the discussion: [Notebook Migration] Keeping the notebook mapping and Jupyter panel for Python file input
Thanks for taking a look! Just a heads up that this ended up merged in #8544, so what's below is how it works in main now. On the source of truth point, I think we're mostly on the same page. The LLM only supplies the cut points; the text of every cell is sliced straight from the uploaded script, so the model can't add or change any code that shows up in the panel. The ranges also get checked against the script before any cells are built: reversed ones are flipped, ones that run past the file are clamped, and malformed ones are dropped. The part we can't do is semantically check that the lines actually match what the UDF does, so a well formed but wrong range would still give misleading highlighting (but we are willing to accept that as LLMs can't be guaranteed reliable). Overlaps and gaps work pretty much the way you describe. Lines that two operators both claim become one shared cell that highlights for both, and a gap becomes its own cell that no operator claims, so it stays visible and just doesn't highlight anything. The one exception is a gap made up entirely of blank lines, which gets dropped so Jupyter doesn't show empty cells. The runnable vs. "came from these lines" distinction is a really good one. If I'm understanding it right though, it doesn't cause problems today, since the panel is read only and never runs anything. The menu and toolbar are hidden, cells can't be edited, and the run shortcuts are disabled. So the cells are really just a display unit for highlighting, and a cell that couldn't run on its own isn't an issue yet. If we ever let the panel execute code, though, that would definitely need revisiting. GitHub link: https://github.com/apache/texera/discussions/8489#discussioncomment-18822830 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
