$ show spyder-ide/spyder
Spyder is a scientific Python IDE built on a plugin-based architecture using Qt (PyQt5/PyQt6/PySide6). It provides a multi-language code editor with Language Server Protocol (LSP) integration for completions, diagnostics, and formatting, an IPython/Jupyter console with custom kernel management, a variable explorer for inspecting NumPy/Pandas objects, a debugger, profiler, and a help system that renders documentation with MathJax for mathematical notation. The main entry point is `spyder.app.start:main`, which initializes the main window and loads plugins discovered via setuptools entry points under the `spyder.plugins` group. Each plugin (e.g., Editor, IPythonConsole, VariableExplorer) is a self-contained module with its own configuration page, container widget, and status bar integration. External dependencies include `spyder-kernels` (custom Jupyter kernels), `python-lsp-server` (LSP backend), `qtconsole` (Qt-based console widget), and `spyder-remote-services` (remote kernel execution via JupyterHub). Data flows: user edits code in the editor, which communicates with the LSP server for completions and diagnostics; running code sends it to the IPython kernel, which executes and returns results displayed in the console and variable explorer. The architecture is a monolith with a formal plugin API that supports lifecycle hooks, dependency management, and configuration observers.
The LLM identified 4 files worth highlighting for reuse:
Implements an LL(1) parser for snippet grammar using a context-switching pattern to build an abstract syntax tree. The parser is self-contained, handles nested structures, and can be extracted for any snippet or template language parsing task.
Provides a generic Emacs-style kill ring implementation (`KillRing` and `QtKillRing`) for text editing. The `QtKillRing` integrates with QTextEdit via clipboard operations and supports yank-pop. It is fully standalone and reusable in any Qt-based text editor.
Defines `on_plugin_available` and `on_plugin_teardown` decorators that register callback methods for plugin dependency events. The pattern uses a registry to wire lifecycle hooks at class definition time, enabling clean dependency management without tight coupling. Could be extracted for any plugin system with dependency ordering.
Implements `send_request`, `send_notification`, `handles`, and `class_register` decorators that build a dynamic method dispatch registry for LSP client handlers. This pattern allows LSP methods to be registered declaratively and dispatched based on method name, enabling clean separation of protocol handling. Reusable for any JSON-RPC client implementation.