[serhiy-storchaka]

Add an AST Browser to IDLE's new Browse menu (Shell and editor). It shows the abstract syntax tree of the editor content, the Shell input, or the selection, as a tree whose rows name the field, the node type, and its simple fields inlined.

Selecting a node highlights the matching source in the editor and, while the browser has the focus, moves the cursor there; selecting text or moving the cursor in the editor selects the innermost node that encloses it. Double-clicking a node expands or collapses it, and Escape hides the browser.

Node columns are UTF-8 byte offsets, converted to editor columns against the source lines; the second commit splits those lines at newlines only, so that a form feed does not shift every following line.

There is one browser per editor, and invoking the command again refreshes it. A selection that does not parse on its own is reported in the status bar, since ast.parse is all or nothing.

The window follows the configuration: its title names the browsed file, the tree takes the current theme's colors and the editor's font with a row height to match, and open browsers are restyled when the configuration changes. It opens beside the editor, its tree takes the focus so that Up and Down work at once, and selecting it from the taskbar reveals its editor.

The first two commits add the Browse menu and the restyle hook that this PR shares with the token (#152946), bytecode (#152974) and character (#152945) browsers; whichever of the four lands first brings them in, and the others drop them on rebase.

🤖 Generated with Claude Code

• Issue: IDLE: add an AST browser #152942

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #34282278 | 📁 Comparing 251145a against main (ac1acb6)

  🔍 Preview build  

179 files changed · + 4 added · ± 175 modified

+ Added

• library/asyncio-tools.html
• library/time-complexity.html
• library/tkinter.fontchooser.html
• library/tkinter.systray.html

± Modified

• glossary.html
• index.html
• license.html
• py-modindex.html
• c-api/arg.html
• c-api/capsule.html
• c-api/exceptions.html
• c-api/float.html
• c-api/import.html
• c-api/init_config.html
• and 165 more...

[terryjreedy]

Using the extension mechanism is handy for developing mulltiple features whose patches would confIict, but I really do not want to merge this way. I added comments about integrating features into normal code. (Not sure if complete.)

[terryjreedy]

These extension def entries do nothing.

[terryjreedy]

Please no. Just import files in code in the appropriate place. (See next comment.)

[terryjreedy]

Menu entries defining tool menu entries and virtual events should be added here. Each browser patch will have have to be finalized by basing it on the code as modified by the previous browser patch. Currently, corresponding objects are imported in editor.Editor and bound to events in init. (Yes, refactoring is needed.)

[terryjreedy]

News3 items have to be added just before merging. I believe that this will be a merge conflict as soon as something else is added.

[bedevere-app]

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

And if you don't make the requested changes, you will be put in the comfy chair!

[serhiy-storchaka]

Done — reworked all four from extensions to integrated features, like the Module and Path browsers.

The three code browsers go on a new Browse menu (your name), stacked token → AST → disassembly. The Character Browser stays on Edit for now so its separate PR doesn't conflict; it can move later.

I kept the News3 entries — resolving the conflict or adding them just before merge is the same edit either way.

Folding the existing Path/Module browsers into Browse is a good follow-up.

[tonghuaroot]

str.splitlines() breaks on several characters that the parser and the Text widget do not treat as line boundaries: form feed \f, vertical tab \v, \x1c-\x1e, \x85, and \u2028/\u2029. When the source contains one of them, source_lines gains an extra entry, and editor_index (which indexes source_lines[lineno - 1] to turn a byte column into a character column) reads the wrong line. Form feed is the realistic trigger, since it is a legal page separator in Python source.

>>> src = "x = 1\f\ny = 22\n"   # a form feed ends the first line
>>> src.splitlines()             # three entries for two real lines
['x = 1', '', 'y = 22']
>>> ast.parse(src).body[1].lineno   # the y = 22 statement
2

y = 22 is line 2 to the parser, but source_lines[1] is now '', so editor_index(2, 4) and editor_index(2, 6) both collapse to column 0 and node_range returns a zero-width ('2.0', '2.0'). show_highlight skips zero-width ranges (rng[0] != rng[1]), so that node highlights nothing; and because the extra source_lines entry shifts every line after the form feed, later nodes have their byte columns converted against the wrong line and highlight or navigate to the wrong place. Restricting the split to the parser's line endings keeps source_lines aligned.

[serhiy-storchaka]

Good catch, thank you. Fixed by splitting on "\n" only, in both the AST and disassembly browsers, each with a form-feed regression test. (A lone \r is a separate parser-vs-Text case I'll handle later.)