Ah, I forgot that.
But, I just tried it again and remembered the weaknesses of the current scel autocompletion and method argument help:
Autocompletion takes a partially entered keyword and present a flat list of left-matching keywords. In most code editors, you can narrow the list down further by continuing to type – e.g., in IDE, type
LFP and the class name completion menu will present the options LFPar and LFPulse. Type a
u, and the list reduces to only
LFPulse, at which point you can hit return to accept. In sc-el currently, you have to switch gears mentally away from typing and toward menu selection.
- IDE: L F P u <return>
- scel: L F P C-c C-n <down-arrow> <return>
It’s “there” but it’s less user-friendly.
Suppose I create an
a = Rect(0, 0, 100, 100);.
- Now I type
a.move and C-c C-n. I get every method name beginning with
move. There is no way to narrow the list down by class. The IDE at least presents some information about who implements the method selector.
- OK, so I’ve got
a.moveTo( and I do C-c C-m. The result is… nothing. Argument lists are not accessible for any instance methods, only for class methods. This means it’s an incomplete feature, as the vast majority of methods are for instances – so the feature works in a minority of cases.
At one point, someone had forked version of sc-el where argument look up worked like this:
- If it could identify a class e.g.
Rect.new(), it would automatically present arguments for the class method.
- Otherwise, it would present a list of classes that implement the method selector. After choosing, it would show the arguments for that method.
Unfortunately I a/ can’t find that fork anymore and b/ SC has diverged too far from it so there isn’t a clean way to merge back to SC today.
I would seriously consider going back to sc-el if you could look up arguments for instance methods. Without that, realistically, it’s not quite usable for me. I actually like Emacs as an editor better than the IDE, but I need fully functioning completion.
That would be a very excellent spot of gravy!
Installation (Linux): I’ve been building sc-el and installing to the default location
/usr/local/share/emacs/site-lisp/SuperCollider – I’m afraid this is not sufficient for
(require 'sclang) alone to find the module. I did have to
(add-to-list 'load-path ...) – then, no problem.
For the help system, the README should probably say that
(require 'w3m) is not necessary in a Qt-enabled build. That is, the README currently says you must require w3m “for the HTML help system to fully function” but
Help.gui does fully function (and is bound within sc-el code!), outside of Emacs, so w3m is needed only for no-GUI builds.