Much of SCEL’s code dates back 20 years, before SCDoc and the help GUI existed.
Modern alternatives like s.makeWindow are great if they fit your workflow.
But SCEL has real value for developers who prefer text editors, and there’s plenty
of room to strengthen it. The core limitation is architectural: OSC is
request-response, so SCEL can only query what it explicitly asks for. Without
built-in callbacks or event-push, real-time reactivity requires constant
polling, which isn’t practical. A proper callback mechanism would significantly
change that. LSP has been discussed since 2018 as a better long-term foundation.
@scztt did excellent work on VSCode + LSP support (well-done), which remained active through
at least last year or this year. That’s a promising direction, but it’s a larger undertaking.
In the meantime, there are concrete improvements SCEL can make today with its
current infrastructure:
-
Better contextual completion — Analyze the scope of a statement as you type
to suggest relevant symbols. Inside a Synth? Show UGens. Calling a method?
Show its signature. This is pure parsing, no polling needed. -
On-demand introspection — Hovering or right-clicking triggers a one-off
query: “What methods does this class have?” “Where is it defined?” These work
fine over OSC. -
Richer evaluation feedback — Capture and display what sclang
returns—types, values, side effects—inline. Even preview some evaluations
before full execution. -
Indexed local cache — Build and update on demand for instant navigation
through classes, methods, and definitions. -
Integrated help — Query SCDoc from within the editor, surfacing docs as you
type or on request. -
Better synth/server inspection — Display available synths, UGens, buses, and
buffers as interactive lists.
These don’t require those architectural changes — just focused work on what’s already
possible with scel.