FROM What is your emacs configuration? (+ my personal bugs):
[just forking as a separate topic, that’s a necessary discussion]
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. -
evaluation feedback — Capture and display what sclang
returns—types, values, side effects—inline. Even preview some evaluations
before execution (think in Patterns, for example) -
Indexed local cache — Build and update on demand for instant navigation
through classes, methods, and definitions. -
help — Query SCDoc from within the editor, surfacing docs as you
type or on request. -
synth/server inspection — Display available synths, UGens, buses, and
buffers as interactive lists. [Broken NOW]
These require just focused work (no waiting)